Convergence and residuals
The bottom dock plots residuals live, per equation, on a log scale. It is the most-watched thing in the application and the most over-interpreted.
Falling residuals prove something real and quite narrow. The gap between what they prove and what people take them to prove is where a large fraction of wrong CFD results live — because a wrong answer converges exactly as tidily as a right one.
What a residual is
Section titled “What a residual is”Take the current field. Substitute it into the discretised equation for that field. The two sides will not balance exactly, because the field is not yet the solution. The imbalance, summed over the cells and normalised, is the residual.
Two properties follow, and both matter:
It measures how far the field is from satisfying the equations — not how far it is from the right answer. These are the same thing only if the equations are the ones you meant to solve, on a mesh fine enough to represent the flow. Neither is something the residual can check.
It is normalised, and the normalisation is not universal. OpenFOAM scales the residual by a factor derived from the field itself, which makes the number dimensionless and comparable across iterations of the same run. It does not make 10⁻⁵ in one case mean the same as 10⁻⁵ in another. Comparing absolute residual levels between cases, or between codes, tells you very little.
The values plotted are initial residuals — the imbalance at the start of each outer iteration, before that iteration’s linear solve. That is the useful one: it says how much the field still has to change.
What falling residuals do prove
Section titled “What falling residuals do prove”That the iterative process is making progress towards a solution of the discrete equations, and that the numerics are stable enough to keep making it.
That is worth having. A run whose residuals fall steadily by several orders of magnitude is not fighting its own numerics: the relaxation is workable, the mesh is not defeating the schemes, the boundary conditions are at least self-consistent. Those are real facts and they are not nothing.
What they do not prove
Section titled “What they do not prove”Not that the mesh is fine enough. The discrete equations on a coarse mesh have a solution, and the solver will find it precisely. Tight convergence on a coarse mesh gives you an accurate answer to the wrong discretisation. See Mesh independence.
Not that the physics is right. A case with the inlet velocity on the wrong patch, the viscosity in the wrong units, or a symmetry plane where there should be a wall converges beautifully. It is the answer to a different question, asked very precisely.
Not that the turbulence model is appropriate. Every model on the list converges. See Choosing a turbulence model.
Not that the flow is steady. A steady solver on an unsteady flow drops a few decades and plateaus, and the plateau reads as “nearly converged” on the residual plot. See Steady or transient.
Not that the answer has stopped changing. This is the subtle one. Residuals can fall while the quantity you care about is still drifting — particularly a force coefficient, which is an integral over a surface and can keep moving after the volume residuals have come down. The residual is about equations. The coefficient is about the answer. They are not the same signal.
Nothing at all from the magnitude alone. Because of the normalisation, “we converged to 10⁻⁶” is a statement with no fixed meaning outside the run that produced it. It is a stopping criterion, not a certificate of accuracy.
The better tests
Section titled “The better tests”Monitor the quantity you will report
Section titled “Monitor the quantity you will report”This is the single most useful change to how you judge a run. Put a monitor on drag, lift, mass flow, pressure drop, outlet temperature — whatever the case is for — and judge convergence on its trace.
The report’s verification checklist does exactly this. It measures the largest movement over the last fifth of the run in the quantities the report headlines, scaled against each quantity’s own range rather than against its absolute value, and reports the drift as a percentage with the threshold stated. Scaling against the quantity’s own range matters: a probe sitting in near-still flow has a mean close to zero, and a percentage against that is a huge number that means nothing.
A quantity that has settled has settled. A quantity that is still drifting has not, whatever the residuals say.
Check the balances
Section titled “Check the balances”What goes in should come out. The checklist sums the flux across every patch and reports the net as a percentage of the throughput. A large imbalance means the run is not converged, or the domain leaks — a patch that should be a wall and is not, or a boundary condition that is quietly a source.
This is a physical check rather than a numerical one, which is what makes it valuable: it is an independent statement about the solution.
Look at the field
Section titled “Look at the field”A slice through the middle coloured by velocity, early. Flow going the wrong way, a wake on the upstream side, or a recirculation filling the whole domain is decisive information and it arrives long before any residual criterion is met.
Reading the plot
Section titled “Reading the plot”The residual plot shows one curve per solved field — velocity components, pressure, and the turbulence quantities.
Pressure is usually the slowest. In an incompressible solver the pressure equation is elliptic — a change anywhere affects everywhere — and it is the expensive, slow-converging one. Velocity and turbulence residuals falling well ahead of pressure is normal.
| What the plot shows | What it usually means |
|---|---|
| Steady fall over several decades | The run is doing what it should |
| Fall, then a flat plateau | Either converged to the residualControl floor, or an unsteady flow, or a mesh quality limit. Check the monitors before adding iterations |
| Fall, then a regular oscillation | Very likely an unsteady flow being solved steadily |
| Flat from the very beginning | Something is not being solved. Over-relaxed, or a field that is not actually free to change |
| Slow, shallow fall throughout | Often heavy under-relaxation: each iteration changes the field very little, which looks stable and is simply slow |
| Rising | Diverging. It will not recover on its own — stop it |
| A value that is not a number | Diverged already. The run is over whatever the counter says |
The application watches for the last two itself: a non-finite residual, or a pressure residual growing over the course of the run, is reported as divergence rather than left to run to the iteration limit and be read as a result.
Under-relaxation is worth understanding here, because it makes the plot misleading in a specific way. Relaxation factors limit how much each field is allowed to change per iteration; lowering them stabilises a difficult run. But a heavily under-relaxed run changes the field very little per iteration, and a field that barely changes produces a small residual. The plot looks calm. The solution is simply crawling. Again: check the monitored quantity, not the residual.
Where convergence criteria live
Section titled “Where convergence criteria live”The Numerics panel has a Convergence section with a residual threshold for
pressure and one for velocity. These write into the solver’s residualControl
block. When both are met, the steady solver stops early and reports that it
converged.
Two things to be clear about:
It is a stopping criterion. Reaching it means “the run stopped because the imbalance got small”, not “the answer is right”. Everything on this page still applies.
Not reaching it is not necessarily failure. A run that hits the iteration
limit with settled monitors and closed balances has produced a usable answer. A
run that hits residualControl with a drifting force coefficient has not. The
report’s checklist reports both facts separately — whether the run reached its
end, and whether the quantities settled — because they are different questions.
Transient runs are a different thing
Section titled “Transient runs are a different thing”In a transient run, convergence is a property of each time step, not of the run.
Every step, the solver iterates within itself — that is what the outer correctors in PIMPLE are for — until that step’s equations are satisfied, and then advances. The residual plot across the whole run therefore shows the per-step convergence level repeated, not a long descent.
A transient residual plot that is flat and low across the entire run is normal and correct. It is not a stalled solve. What you are looking for is that the level stays low and does not creep up, which would say the steps are no longer converging within their correctors — usually because the time step has grown too large, which is a Courant number question.
The convergence question that matters for a transient run is a different one entirely: has it run long enough? That means clearing the initial transient and then averaging over enough periods, and it is judged on the monitor trace, not on residuals at all.
Where you act on this
Section titled “Where you act on this”- Reference → Numerics panel — relaxation factors, residual thresholds, schemes and linear solvers
- Reference → Result control panel — adding the monitors that make convergence judgeable
- Reference → Report — the verification checklist and its thresholds
- How-to → Diagnose a diverging run
- Troubleshooting — indexed by the error on screen
- Verification and validation — where iterative convergence sits among the things that make a result evidence