Troubleshooting
Solver errors, unstable models and results that look wrong — with the usual causes listed first.
Troubleshooting 2 min read
Most problems in a finite element model are modeling problems in numerical disguise. This section lists the causes that actually occur, in the order they occur.
In this section
- 01Solver errorsWhat each class of solver message means, what usually causes it, and what to do next.
- 02Why the solver reports a singular stiffness matrixThe most common solver failure — what singularity means mechanically, the six causes in order of frequency, and how to find yours in minutes.
Triage in four questions
- Did it solve at all? If not, it is almost always a restraint problem — go to singular stiffness matrix.
- Does the deflected shape look like the structure? Amplify the deformation and look. A member flying off, a floor rotating about the wrong axis or a support moving tells you more than any table.
- Do the reactions balance the applied load? Compare per case. A mismatch means load went somewhere you did not intend — often onto a support you forgot was there.
- Does one member check out by hand? Take the simplest span, apply , and compare. This catches units, load extents and section assignment in one step.
Symptoms and usual causes
| Symptom | Look at first | Article |
|---|---|---|
| Solver reports the model is unstable | Missing restraint in a direction; a member released at both ends | Singular stiffness matrix |
| Displacements enormous but finite | Very soft spring, wrong material modulus, or a section assigned in the wrong units | Singular stiffness matrix |
| Displacements essentially zero | Load applied to a case that is not in the combination being viewed | — |
| Moments at a support far higher than hand calculation | Point support singularity — read at the face, not the node | Choosing element size |
| Plate results change every time the mesh changes | Mesh not converged, or a genuine singularity | Choosing element size |
| Reactions do not sum to the applied load | Load on an unconnected node, or applied over the wrong length | — |
| Check reports zero utilisation | No design combination assigned, or the member has no section | — |
When it is genuinely us
If a result disagrees with a hand calculation or a published benchmark and you have ruled the above out, that is a bug worth reporting. Send the project and the calculation you compared against to [email protected]. During the beta these reports go straight to the person who wrote the solver, and the fix usually ships with a note in the release notes.
Something wrong or unclear on this page? Tell us, and it gets corrected.