This article is part of a series on the use of Marc and Mentat.

Because Marc can solve such a large set of physics, the number of things that can go wrong is pretty large. In this first article we’ll be looking at convergence problems and how to overcome them.

Introduction

Getting linear FEA (Finite Element Analysis) models to solve are simple – after all, in order to solve we only need:

• A valid mesh (elements not too distorted to solve)
• Valid Material constants and Geometric properties
• Enough constraints to remove all rigid body motion

Note that this is what is needed to solve, not what’s needed for correct answers.

For non-linear analysis further problems creep in, resulting in a lot more that can (and often does) go wrong.

One of the most common problems is non-convergence of models: The FEA (Finite Element Analysis) solver keeps on iterating. It does not converge in the allowed number of iterations. It then tries a smaller step. No convergence again. This repeats until either the load change is so small that the solver reaches a minimum step and stop or the user gets bored and kill the run.

With more than ten years of experience debugging non-linear models (my own models and those of clients), I have found that the number one reason for convergence problems is that there is something wrong with the question you’re asking from the solver. Some critical bit of physics is not included in the model. This may be a missing constraint, contact that is not included, friction that is excluded or a yield-curve that is unstable.

Typical reactions to models that does not converge are to decrease the minimum step-size allowed or else to loosen the convergence tolerances. The former increases runtime while still not converging. The latter reduces the accuracy significantly while not addressing the underlying problem(s). Next, the User tries to allow the solver more iterations in an attempt to help convergence. This sometimes works, sometimes not at all. Contact settings are changed. Material settings are changed. Constraints are changed.

As can be imagined, this approach of randomly trying stuff in order to get the model to run is very inefficient. Especially since the problem in all likelihood was missing physics.

In this post, we’ll discuss some causes of non-convergence. More importantly, we’ll discuss ways to systematically approach debugging of non-linear Finite Element models. While some of this is generic to any FEA code, the brunt of this article is on debugging Marc models.

Load increments

In nonlinear analysis, we usually increase the applied load “slowly”. For each load-step attempted (an increment) the solver will iterate until convergence criteria are met. At this point the results will be written and the next step attempted. A smaller load increment is usually significantly closer to linear which results in easier convergence.

Note that contact is one possible exception to this rule, but we’ll discuss it later.

In Marc / Mentat, any load has the option to be scaled as a function of “time”, using a “table”. If you’re not familiar with “time” or “tables” in Marc, please read the relevant section in the Mar101 training material which is part of the standard documentation for Marc / Mentat.

If the user chooses NOT to link a table to a load, a very nasty problem can creep in: Depending on the load-stepping scheme (adaptive vs. Fixed-step), the solver may assume you want to apply the load in one step. Let’s assume some load is too large to apply in a single step. The solver does not converge when it attempts to apply the load in one step. It reduces the time-step. If the solver thinks you want to apply the load immediately (because you did not specify a table), the full load is applied again with the smaller time-step. This is NOT a solver problem: The user has chosen to specify the load in a very ambiguous way, so the solver is allowed to interpret it as it sees fit.

Linking a table that defines the load-scale-factor as a function of time completely removes the ambiguity. There is no possibility of Marc misunderstanding how your load is applied.

In short, ALWAYS use a table with every load specified for Marc. Doing so may add 30 seconds to model setup-time, but will save you days of debugging time.

Convergence criteria

Convergence criteria define under which conditions the approximate result is “good enough”. “Approximate result” because only linear models can reach perfect convergence. For structural load-cases, Marc allows three types of convergence criteria:

• Displacement
  Convergence is achieved when the maximum change in displacement between iterations is small enough
• Residual (i.e. Unbalanced Force / Moment)
  Convergence is achieved when the maximum difference at any node between the applied load and the reaction-load is small enough
• Energy
  Convergence is achieved when the maximum change in strain energy density between iterations is small enough

The convergence criteria can be based on absolute values or relative values. Relative values tend to be more meaningful since the allowed “error” scales with the applied load. In engineering terms: If the maximum load is 1N, a 10N unbalanced load is unacceptable. On the other hand, if the maximum load is 1MN, a 10N unbalanced load is pretty accurate.

We tend to ignore the “Energy” criterion for a simple reason: Marc allows combining Displacement- and Residual-convergence, but not combining Energy convergence with anything else.

There are times when one or another cannot converge with “relative” checking:

• If the load stays constant between consecutive steps, the calculated displacement for both should be the same. The residual convergence check is automatically passed for the second step because it was already satisfied for the previous step. Displacement convergence is near-impossible because the change in displacement is zero, and the zero appears above and below the line. Zero divided by zero is any number you want it to be…
• If the applied load perfectly balances, the reaction forces can be zero. Since relative residual checking divides by the reaction force, we again end with a case of zero divided by zero.

In other words, the model may be converged even if one of the criteria says otherwise. This is because the criterion in question is not a valid check for that special case.

It is pretty easy to spot these: Look at the log file. It reports the convergence values and the ratios. The example below shows the info in the log file for one of its iterations. Unimportant lines for this example are shown in blue. The “cycle number” is the iteration number. “Recycled” means that it did not converge and that another iteration (recycle) will be performed. In this example, the convergence ratios were 0.001 for both residual checking and displacement checking.

For residual checking, the “residual force” is divided by the “reaction force”, resulting in the “residual convergence ratio”. The residual is therefore converged.

For displacement checking, the “displacement change” (i.e. the change in displacement from the previous iteration to the current) is divided by the “displacement increment” (i.e. the total change in displacement for all the iterations of this load-step) to obtain the “displacement convergence ratio". This example is not converged yet.

start of assembly     cycle number is     5

wall time =          21.00

start of matrix solution

wall time =          23.00

end of matrix solution

wall time =          24.00

maximum residual force at node    167439 degree of freedom 1 is equal to    2.632E+01

maximum reaction force at node    163127 degree of freedom 1 is equal to    1.368E+05

residual convergence ratio    1.925E-04

maximum displacement changes at node    172825 degree of freedom 2 is equal to    2.282E-01

maximum displacement increment at node    172798 degree of freedom 2 is equal to    1.241E+00

displacement convergence ratio   1.840E-01 increment will be recycled.

If either the “max reaction force” or “max displacement increment” was close to zero, it would indicate that either that criterion is invalid or that there is no load yet on the model.

This example also shows that, while the model is nearly in force-balance (because of the low residual ratio), the displacements are still changing by a significant amount between iterations. This points to either:

• A model that has low stiffness in some direction. Otherwise a small change in displacement would cause a large change in either reaction force or unbalanced load
• Contact / Friction that is not yet in equilibrium – some part of the model is still “sliding” into its correct location.

Please note that the default tolerance for Marc is really coarse at “0.1” (or 10%). For residual checking, this would say “if the unbalance load at any node is within 10% of the maximum reaction force, treat the result as converged.” Ouch! Please only use the defaults to verify a model (load-sequences are correct etc.).

In summary, as far as convergence criteria and tolerances go:

• Ensure that your choice of criteria is valid for the type of analysis
• Ensure that your choice of tolerance(s) is much tighter than the defaults if you want reasonable results. This will make convergence harder to obtain, but only because it does not hide the real reason for non-convergence.

Ideally use “residual AND displacement” checking unless one of the two is not valid for some (explainable) reason.

Furthermore, don’t ever change any settings in a model which does not converge before taking a look at the convergence values and rations in the log file. This will show at which node the worst unbalanced load is, in which direction the worst unbalance is, whether the displacement or residual checking is valid for the increment in question and which convergence criterion is the furthest from convergence. This should give a clue as to what the problem may be.

Contact and Friction

Contact and friction typically has two possible effects: It can drastically increase the number of iterations needed for convergence and/or it can cause convergence to become impossible.

The increase in iterations is due to the extreme non-linearity inherent in contact (zero stiffness if no contact, infinite stiffness when in contact) and needing to find out exactly which nodes are in contact.

For models with contact, there are cases where convergence is impossible. This is a physics problem, not a solver problem. Some examples:

• A component “constrained” to another component only via contact, with a load applied that is large enough to cause separation between the bodies does not have a static solution: After separation, the load will cause one body to accelerate which requires a transient solution.
• A similar component that touches another, but without friction, may not be able to withstand loads in all directions without friction. Even if friction is allowed, it will only have a valid solution until sliding start.

A message similar to the following may also appear:

iterative penetration checking has reached   0.180175 of total increment

This occurs when the change is displacement between iterations is so large that the contact behaviour is invalid. It then scales the displacement change down to a more reasonable value (0.18 of the intended increment in the example above). This is seldom a contact problem as it tends to indicate that the model either has no or a very low stiffness in some direction.

A detailed look at contact is a topic for a different post.

Debugging contact is reasonably simple:

1. Check the initial “contact status” result (nodes in contact has a value of “1”). Ensure that all nodes that should start in contact is in contact and that no areas that should not be in contact is shown to be in contact
   If there are regions not in contact which should be, do NOT change the contact distances. It almost always means that your mesh has a problem. Find out what it is and fix the mesh
2. Change all contact to “glued” to see if the model now converges. This is to see if the non-convergence is due to contact.
   • If the model still does not converge, then contact is not (the only) problem in the model. Leave the contact “glued” until the other problem(s) are solved, then start switching back to touching contact
   • If the model now runs, progressively change contact between different bodies back to “touching” to find out which pair(s) causes the problem. Bear in mind that the problem is likely to be “physical” (e.g. convergence is not possible or friction should have been used)
3. Request results for un-converged iterations. This is discussed in more detail in the following section

Iterative results

This is a very powerful debugging tool: It will write partial un-converged results to the results file if requested. Only displacements, reaction force and contact results are available for these. To activate it, switch on the “iterative results” on the results form in Mentat.

This option addresses one of the main problems with debugging non-linear models namely that, since it does not converge, there is no results with which to find out what went wrong. The displacement plots from the un-converged iterations can often be used to find out where the problem is. Examples would be to find:

• Areas that should not move as much
• Contact not being detected correctly due to too large load-steps taken
• Sliding that occurs, possibly causing physical instability

Just remember to switch if off once your model is working – it will increase the results file size by an order of magnitude if left on.

Conclusion

If you do not follow a structured approach to resolving non-convergence, it becomes a hit-or-miss affair. Mostly miss unfortunately.

A suggested structured approach is the following:

• Ensure all loads have a valid table linked to it. Also ensure that the load values are as expected and in the right units
• Check all material constants and tables to ensure the numbers are reasonable
• Check that the convergence criteria and values are reasonable
• Activate "iterative results" in order to see what happens during un-converged iterations
• For contact models, change all contact to glued instead of touching

After running the model for a few iterations, kill the model and have a look at the iterative results. This usually gives clues to the cause of the problem. The convergence values and convergence rates found in the log file is also useful tool to debug non-convergence.

Using such a structured approach can reduce the time required to debug a model significantly.