The solver log

What the Log tab of the bottom dock says while a job runs, and what the Problems tab collects from it afterwards. The two are not the same list: the Log is everything the mesher and the solver printed, and Problems keeps the lines worth acting on, filed under Simulation runs and prefixed with the step that produced them — simpleFoam: , snappyHexMesh: and so on.

See also the diverging-run guide, which is about the shape of the residuals rather than about a message.

Back to Troubleshooting.

---

Nothing was really solved

The two most important messages in the application, because in both cases the run appears to succeed: a mesh is drawn, residuals fall, coefficients appear. Nothing else marks the results as unreal. If either line is in the log, discard what came out of that job.

"Showing the built-in preview instead. These figures are estimates from the case settings, not a mesh."

A Log line, written when meshing is asked for and the fluids backend is not installed. What you get is a projection from the case settings — a cell count, a quality figure — not a mesh. Nothing was run.

"Showing the built-in preview instead. These residuals and coefficients are illustrative, not a solution."

The same thing on the run side. The residual plot and the force coefficients that follow are generated so the interface has something to draw.

"No OpenFOAM runtime. Expected a bundle at <path> (run scripts/fetch-openfoam.ps1), or set SHD_SIMCFD_OPENFOAM_ROOT to an installation root."

The Log line immediately above either of the two above, and the actual reason for them. It is worded for somebody building the application from source, and it does not name the thing you should do, which is:

Settings → Integrations, pick the fluids family, and press Download and install. See Installation.

---

The run stopped and the message says nothing

These are the whole message. They are what the application can say when a process ended badly and printed no reason of its own, and each appears both as a Log line and as the job's failure status.

"simpleFoam exited with code 1."

The step is named after the OpenFOAM application that was running — blockMesh, snappyHexMesh, interFoam and so on — and the number is the process exit code.

The reason is in the Log above this line, not in it. Scroll up. An OpenFOAM application that stops on purpose prints --> FOAM FATAL ERROR or --> FOAM FATAL IO ERROR and then several lines naming the dictionary entry or the field it wanted; those lines are the answer. What gets copied into Problems under Simulation runs is the banner line itself, so that row tells you a fatal error happened and the Log tells you which.

"snappyHexMesh crashed."

The process died on a signal rather than exiting with a code. Same advice: read upward. Segmentation fault and Floating point exception in the log are picked up as problems in their own right.

"simpleFoam failed to start."

The executable could not be launched at all — the backend is missing or incomplete rather than unhappy with your case. Reinstall the family from Settings → Integrations.

"interFoam was aborted by the launcher: a rank exited before the run reached its end."

A parallel run in which one process died and the launcher killed the rest. The exit code on its own would have reported the job as successful, which is why this is worded as it is. The rank that died printed its reason into the log before the others were stopped.

"simpleFoam finished and wrote its results, but the launcher exited with code 1 - usually an untidy MPI shutdown. Treating the run as complete."

Not a failure, and listed here because it reads like one. The application printed End, every result was written, and MPI returned a non-zero code while tearing down. The results are good. A second wording covers the same thing when the process died rather than exited: "…then the process died while shutting down (exit status 0x<code>). Treating the run as complete."

"MS-MPI was not found, so this run is serial. Install Microsoft MPI to use 8 cores."

A Log line. The run is correct, just single-threaded — the core count you set is being ignored because there is no MPI to distribute over.

---

The run diverged

"The solution diverged: the residuals grew instead of falling. Lower the relaxation factors, improve the worst cells on the Quality pane, or start from potential flow."

A Problems entry against Numerics, added when the run finishes. It is raised only for a genuine divergence, and it is deliberately distinct from a failed run — a solver that could not read its dictionary and a solver whose pressure residual climbed until it overflowed need completely different things.

The Log line beside it reads "The run diverged. The last residuals were rising, which is a numerics or mesh-quality problem rather than a set-up error."

The ordered list of things to check is under During the run.

"the time step has collapsed to <value>, below a millionth of the largest used - the solution has almost certainly diverged"

Read out of the log while the run is going, and raised into Problems under Simulation runs. On an adaptive time step this is what divergence looks like before the residuals overflow: the solver keeps cutting the step to stay stable and never recovers.

The earlier, gentler form is "the time step has fallen to <value>, a hundredth of the largest used - the solver is struggling with something. Common causes are a cell too coarse for what is passing through it and a momentum solve that is not converging; the log's own residuals say which". Only one of the two is reported for a given run.

"the Courant number reached 32 against a limit of 0.500000 - the solver took a step far larger than the case allows, so something accelerated sharply between one step and the next"

Raised once per run, when the measured Courant number passes twice the limit set in Simulation control. The limit is printed with six decimal places; that is the message's formatting, not a value you typed.

An adaptive step overshoots slightly by design, so this fires only on a real excursion — something in the flow accelerated sharply between one step and the next.

"a velocity limiter clamped <n> cells (<percent>% of the mesh) in a single step - over that region the velocity is the limiter's value rather than a solution, so results after this point are not trustworthy"

The run continues, and over that region it is no longer solving your problem: the velocity there is the limiter's number.

A milder version fires when the limiter is catching a handful of cells repeatedly: "a velocity limiter has rescued cells on <n> steps - the run continues, but something in the case is producing velocities it should not. Check the initial residuals on the momentum solve: healthy ones mean the mesh is too coarse where the flow accelerates, and a solve running to its iteration limit means the momentum equation itself is diverging".

"bounding omega, min: -4.055916 max: 1112.6518 average: 19.459716"

OpenFOAM's own line, picked up into Problems under Simulation runs. It means a turbulence field went negative and was clipped back to a floor. It appears for k, epsilon, omega and the rest, and it is de-duplicated — it typically prints on most iterations of a run that has it at all, and one entry per iteration would be a list nobody can read.

The application does not judge it, so this page will not either beyond the obvious: a few while the field settles is ordinary, and it running to the end of the case means the turbulence solution is not physical.

---

Wall resolution

Reported once, after a run that converged, as a Problems entry against Turbulence and as a Log line. It is silent when the mesh suits the wall model, so its presence is a finding rather than routine chatter.

This is the only place the application tells you that a successful run is wrong.

"Wall resolution y+ 6.3 to 30.9, average 15.5, and the near-wall treatment is Wall functions. The log law they use begins around y+ 30, so most of body is below the range the model is valid in and the forces on it will be wrong even though the run converged. Switch the near-wall treatment to Automatic blending, which is valid at this resolution, or coarsen the near-wall cells."

The three numbers and the patch name are your own. The judgement is on the average, not the extremes: a stagnation point drives y+ to nearly nothing on any mesh, and a sliver of wall reaching above 30 does not rescue a surface whose typical cell sits well below it.

Note what this implies and does not say outright: refining the mesh makes it worse, not better. A finer near-wall cell pushes y+ further below the log layer.

"Wall resolution y+ <min> to <max>, average <mean>, and the near-wall treatment is Resolved (low-Re), which integrates to the wall and wants y+ near 1. This mesh is too coarse for it to resolve what it is being asked to resolve. Refine the near-wall cells, or switch the near-wall treatment to Automatic blending."

The opposite mismatch, and here refining is the fix.

In both cases Automatic blending is the remedy that does not require getting the mesh right first: it uses Spalding's law, which is continuous from the viscous sublayer to the log layer and so has no band to fall out of. On a blended case the same check reports a plain statement instead, with no severity — "…Automatic blending uses Spalding's law, which is continuous from the viscous sublayer to the log layer, so this mesh is inside its range wherever it sits."

The set-up-time warning that anticipates all of this is on The mesh and the geometry.

---

The plots are empty

"No function objects have written anything to postProcessing/. Forces, coefficients, flow rates and probes come from there — enable them under Result control before running. What follows is read from the solver log instead."

In the Monitors tab of the bottom dock, not the Log. It is not a fault: nothing was asked for. Forces, coefficients, flow rates and probes are opt-in under Result control, and they have to be set before the run that is meant to produce them.

What the tab shows instead is scraped from the solver log, which is why residuals appear and force coefficients may not.

---

Previous: The mesh and the geometry · Next: Tier limits