Reading an Abaqus job that failed
The answer is usually in the files. It is just spread across four of them, and the most informative part is not an error message at all.
A job that will not converge produces four files and no answer. Read in the right order they usually do contain one — and the single most useful thing in them is the shape of the iteration history, which is not an error and produces no message.
What each file is for
| File | Contains | Read it when |
|---|---|---|
.dat | Input processing. Errors here stop the job before it starts | First, always. If the analysis never started, nothing about your material has been exercised |
.sta | One line per attempt: step, increment, attempt, iteration counts, time | To see the shape of the run — how hard every increment was, and where it started to struggle |
.msg | Warnings, errors, and the increment-by-increment record with residuals | To find out what the solver complained about, and to watch a residual stop falling |
.inp | The deck: element types, material constants, step controls | To check that what the deck declares and what the subroutine reads are the same |
The status file, and the mistake everyone makes reading it
The .sta has one line per attempt, not per increment. An increment that gets cut back appears two, three or four times, and the abandoned attempts carry a U on the attempt number.
1 1 1 0 4 4 0.0100 0.0100 0.0100
1 2 1U 0 16 16 0.0350 0.0100 0.0250
1 2 2U 0 16 16 0.0163 0.0100 0.0063
1 2 3U 0 16 16 0.0116 0.0100 0.0016
1 2 4U 0 16 16 0.0104 0.0100 0.0004Counting the lines gives five increments and a job that sailed along. It got through one. The U is the entire record of a cutback, and cutbacks are the most informative thing in the file.
The shape of the history is evidence
The column that matters is equilibrium iterations. A tangent consistent with the stress update gives quadratic convergence — three or four iterations, whatever the material. Read the median, not the mean: one sixteen-iteration attempt before a cutback drags a mean far enough to call a healthy job slow.
| Median iterations | What it means |
|---|---|
| 3 to 4, no cutbacks | A consistent tangent. This is what you are aiming at |
| 6 to 12, no cutbacks | The tangent is close but not consistent — typically a continuum form where the algorithmic one is needed. The answer is right; the run time is a multiple of what it should be, and the increment size will never grow past the default threshold |
| Repeated cutbacks to the floor | Equilibrium was not reached at any increment size. A tangent error does not shrink with the increment, which is exactly why cutting back did not help |
The messages worth recognising
| What the solver says | What it usually means |
|---|---|
| Too many attempts made for this increment | Cut back repeatedly, never converged. If lowering the increment did not help, the cause does not shrink with the increment — which points at the tangent or at a discontinuous stress update |
| Time increment required is less than the minimum specified | The same failure from the other side. Lowering the minimum converts a job that fails in ten minutes into one that fails overnight |
| The solution appears to be diverging | The residual grew. With a correct tangent that happens when the start point is far from the solution; with a wrong one it happens every increment |
| The strain increment has exceeded fifty times the strain to cause first yield | On the first increment, reduce the step. Throughout, the iteration is overshooting and the tangent is the place to look |
| A value which is not a number | A division by something zero on the first increment, or a square root of something negative. The flow direction divides by the equivalent stress, which is exactly zero at an unloaded point |
| Zero pivot / numerical singularity | Check the restraints first — a rigid body mode has nothing to do with the material. Then check that DDSDDE is assigned on every path |
The checks that cost nothing
Before reading any of it, compare the deck against the code. Two numbers, and both fail silently:
CONSTANTSagainst the highestPROPSindex you read. Too small and you read past the end of the array.- **
*DEPVARagainst the highestSTATEVindex you write.** Too small and you corrupt memory Abaqus owns, and the symptom is a result that changes with the mesh.
The single-element test
One element removes everything that is not the material: no mesh sensitivity, no hourglassing, no contact, no geometry. If a one-element job disagrees with your material-point calculations, the disagreement is in the subroutine or in the way Abaqus is calling it, and nothing else is left to blame.
Three symmetry planes and a prescribed displacement on the opposite face give a uniaxial stress state with free lateral contraction. Make the element a unit cube and the prescribed displacement is the strain and the reaction is the stress, so no conversion is needed to compare against a hand calculation.
Write down what the stresses should be before running it. A test with no expected result is a demonstration.
Common questions
Should I lower the minimum time increment to get past a cutback?
Rarely, and not as a first move. It helps when the difficulty is genuinely local and transient — a contact event, a sharp load change.
It does not help when the cause is a tangent or a convention error, because those do not shrink with the increment. All it buys is a job that fails later.
How do I tell a material problem from a contact problem?
The severe discontinuity iteration column in the .sta separates them. Contact chatter shows up there; a bad tangent shows up in the equilibrium iteration column.
A material-point check settles it entirely: if the tangent and the physics both pass outside the solver, the problem is in the model rather than in the material.
My job converges but takes forever. Is that a material problem?
Look at the median equilibrium iterations. Three or four means the material is fine and the cost is elsewhere. Eight or more means the tangent is approximate, and that is worth a day of your time to fix because it multiplies every run you do afterwards.