Diagnose a diverging run

The residuals are rising, or the solver stopped, and you want to know which of the four usual causes it is.

This page is the order to check things in. The messages themselves are indexed in Troubleshooting.

Stop it first

A diverging run does not recover on its own. Select Runs and press Stop gracefully — it writes the current step out before exiting, which leaves you something to look at. Kill does not, and asks before it does.

Then work down this list

1. Read the Problems tab. It reports what is wrong before a run, and it is the easiest part of the interface to skip. Red means the run will fail or produce nonsense.

2. Look at where it fell over. The Log tab, not the summary — OpenFOAM names the entry or the cell it objected to on the last line.

3. Check the mesh. Quality reports non-orthogonality, skewness and aspect ratio. A poor mesh where the flow is interesting usually announces itself as divergence rather than as a meshing failure. Apply to numerics adapts the schemes to the mesh you actually have.

4. Check the time step, for a transient case. Simulation control → Max Courant, with Adjust time step to Courant number on. The hint states the ranges the two algorithms tolerate.

5. Check the boundary conditions are physical. A pressure outlet on the inlet side, or velocity specified into a wall, will not settle. Each patch’s This writes block shows exactly what it produces per field.

6. Back off the numerics. Numerics → the Robust preset. Relaxation that is too aggressive for the case is the fourth of the four causes, and the cheapest to test.

7. Improve the start. A transient run from rest, or a steady run from a uniform guess on a long internal-flow domain, spends its early iterations in a state the solver was never meant to handle. See restart from an existing solution.

When it stops with nothing useful

Runs → Trap floating-point exceptions decides what happens when a NaN appears. On, the run stops at once, which is what you want while a case is being set up. Off, it runs on — some turbulence models form a quotient and clip it immediately, and the trap fires on the quotient rather than on the result, so a healthy run dies with no message. If a run dies silently and early, try it off.

Flat is not the same as diverging

Residuals that go flat well above convergence have stopped improving, not diverged. That is usually too coarse a mesh, or a genuinely unsteady problem being solved as steady — a steady solver applied to vortex shedding sits at a plateau forever, because there is no steady answer to find.

Check it worked

• Residuals fall steadily by several orders of magnitude.
• The Result block on Runs gives a mass balance near unity.
• The verification checklist in the Report passes, with the threshold behind each verdict stated.

Related: the residuals rise instead of falling — indexed by the symptom rather than the intent.