9.12 Limitations of FEBio¶

If you run into a problem that you can't seem to solve, maybe you ran into a limitation of FEBio. This section discusses some important limitations of the software and how they may affect the outcome of your analysis.

Geometrical instabilities¶

A geometrical instability is a point in the solution at which several paths for continuing the solution are possible. Typical examples are buckling of a column. FEBio's Newton based solvers cannot handle buckling since usually at these points, the material's elasticity tangent is not uniquely defined. Although in some cases FEBio will be able to pass a buckling point, in most cases, FEBio will not be able to converge to a solution.

Material instabilities¶

A material instability is a point in the stress-strain response where the slope of the stress-strain curve effectively becomes zero. Since FEBio's Newton based solvers use this slope to advance the solution, a zero slope would mean an infinite step and FEBio will not be able to continue.

The slope (or more accurately the elasticity tangent tensor) does not have to be zero to cause problems. For materials that soften at large deformations, this slope may become so small that it renders the global stiffness matrix ill-conditioned. It is unlikely that FEBio will be able to continue and even if it finds a solution, it may not be useful.

Remeshing¶

FEBio is designed to solve problems that can undergo large deformations. However, when the deformations become too large it can happen that the finite element mesh cannot be distorted any further without inverting elements. In that case, FEBio will not be able to continue the solution and will most likely terminate with a negative jacobian error message.

One possible solution to this problem is to remesh the model at the point at which the deformation become too large, but currently FEBio does not have any remeshing capabilities. The only remedy at this point is to plan ahead and design your mesh in such a way that the elements will not invert in the range of deformation that you are interested in (e.g. place a butterfly mesh in sharp corners or make the mesh finer in areas of larger deformation).

Force-driven Problems¶

When the primary method of deforming the model is a force, the problem is said to be force-driven. (Opposed to a displacement-driven model where the deformation is caused by displacement boundary conditions.) Force-driven forces are inherently unstable and FEBio has limited capabilities of handling such problems¹. The cause of this instability can easily be explained using a simple example. Imagine a box that is constrained in all directions except one. In the unconstrained direction, apply two equal but opposite forces on opposite faces. In order to prevent the box from flying away, the box must generate stresses which balance the applied forces exactly. Unfortunately, the numerical solution will only be approximate due to numerical round-off errors inherent in the calculation. Even the slightest deviation from balancing the forces exactly will create a net-force which in turn causes the model to fly off in the unconstrained direction (in which a rigid body mode now exists).

Usually, these problems are circumvented by adjusting the boundary conditions so that rigid body modes cannot exist. In the previous example this can be done by only modeling half of the box and enforcing a symmetry boundary condition. However, in some cases this is not possible. This is often the case in force-driven contact problems, where the contact interface is necessary to define a well-constrained model. When there is an initial separation (or even when the surfaces have no initial overlap) the initial contact force is zero, which is equivalent to having no contact enforcement, and thus the model is under-constrained. Therefore, for force-driven contact problems it is important to have some initial contact before starting the analysis.

Solutions obtained on Multi-processor Machines¶

Although technically not a limitation of FEBio it is important that users are aware that in some cases you may get a different convergence history or sometimes even a slightly different answer when you run the same model twice on a multi-processor machine. This is caused by the fact that on multi-processor machines the same calculations can be executed in a different order and due to the accumulation of numerical round-off errors may result in slightly different answers. The type of problems that are mostly affected by this are problems that are close too being ill-conditioned. Also, problems that have many time steps or require many iterations for each time step may be affected by this.

If you experience different answers for the same problem, try running the model on just one processor (if possible). See Section Using Multiple Processors for more information on how to run FEBio on multi-processor machines.

As of FEBio 2.0, some features are available that may help with this issue, but they are still experimental. ↩