Draft. This manual is new and still growing. If something here does not match what you see in the software, the software is right — tell us and we will fix the page.

The mesh and the geometry

Everything here is reported before a run, in the Problems tab of the bottom dock, under Quality, Mesh, Geometry or Boundary layers. Several are the reason a case that meshed perfectly then diverged, so they are worth reading even when the mesh looks fine in the viewport.

Where a message names a number from your own mesh, the number is shown here as a placeholder in angle brackets.

Back to Troubleshooting.

The mesh will not solve at all

"The mesh has cells with an aspect ratio of 8.2e+100 - they have been squashed flat, most likely by the boundary layers. The solver cannot use this mesh: the pressure equation diverges immediately. Reduce the layer count or the expansion ratio and mesh again."

An error against Quality. The exponent is your mesh's measured aspect ratio and it is usually astronomical rather than merely large — a collapsed cell is not a slightly bad cell, it is an infinity in the pressure matrix.

The cause is almost always the boundary-layer stack: layers added into a space too small for them flatten the cells they were inserted into. Reduce the number of layers or the expansion ratio and mesh again. There is no version of this mesh that produces a usable answer, which is why it is an error rather than a warning.

An error against Quality. One is enough to stop the run. It appears as surface refinement rises — a level that meshed cleanly can produce inverted cells one level finer — and a two-dimensional case is the usual victim, because the same refinement in 3-D often has none.

"Max non-orthogonality 74.3 deg exceeds 70 - the run is likely to diverge."

An error against Quality, carrying your mesh's own figure. Below that threshold and above 60 the same measurement is reported as a warning that says what was done about it instead: "Max non-orthogonality 63.1 deg - schemes set to 'limited 0.5' with 1 non-orthogonal corrector." That one is informational — the schemes have already been adjusted for you.

The geometry

"The imported surface has open edges. It will still mesh, but the flow can leak inside the body through the holes, which usually shows up as a run that diverges rather than as a meshing failure. Cap the holes, or place the body on a ground plane if it was modelled to sit on one."

A warning against Geometry, and the single most useful entry on this page if you have arrived here from a diverging run. The mesh succeeds. checkMesh is happy. The flow then finds its way into the interior of the body through the holes and the case never settles.

Two common causes, and the second is not a defect in the file: a surface with genuine holes needs capping, and a body modelled to sit on the ground is open at the bottom by design and needs a ground plane under it.

"No geometry has been imported. The mesh will be the empty domain box - flow from the inlet to the outlet with nothing in the way. Import a body under Geometry, or choose a shape that is its own domain (a tank, a cavity, a duct) from the catalogue."

A warning against Geometry. It is not an error, because an empty box with an inlet and an outlet is a legitimate case and a half-set-up case is exactly what this state usually is. But it is the one thing the mesh will never make obvious: the background block mesh generates, the solver runs, and the answer is of nothing.

Cases that are their own domain — a vessel, a periodic box, an engine, a channel — and cases using an imported mesh do not raise it.

On the finite-area analyses, where the solution lives on the body's surface, the same situation is an error instead: "This analysis solves on the surface of a body - the film lives on it - and no geometry has been imported, so there is no surface to mesh. Import a body under Geometry, or load the worked example." It says surfactant in place of film for the surfactant solver.

"<file> is still loading. Meshing now would mesh the empty domain box instead of the body."

An error against Geometry, and a timing problem rather than a fault. A file has been chosen and the body has not arrived yet. Wait for it.

"<file> was imported but no body came of it (<status>). Meshing would use the empty domain box. Re-import it, or check the file."

An error against Geometry. The import completed and produced nothing usable; the bracketed part is the importer's own account of what happened. Every pane in the case will still describe the model you intended, which is what makes this worth catching before the mesh rather than after the run.

Set up against a mesh that does not match

"The patches inlet, outlet are not in the mesh, so what is set on them will have no effect. The mesh has: <the patch names it does have>."

A warning against Boundary conditions, listing what the mesh actually contains. The singular form is "The patch "inlet" is not in the mesh, so what is set on it will have no effect."

This is normally a case set up before the geometry was imported, or a mesh that renamed patches on the way in. Nothing is lost — reassign the conditions to the names the mesh has.

"<control> measures the patch "body", which this case does not have - most likely it was set up before the geometry was imported. It will not be written; pick one of: <patch names>."

The same fault on a result control, reported against Result control. The control is silently absent from the results rather than wrong, which is why it is said here.

Boundary layers

"Layer coverage 21% on patch 'body'. That is low enough that the stack is costing mesh quality rather than buying wall resolution - compare checkMesh with the layers off before keeping them."

A warning against Boundary layers. Below about a third of the patch covered, the layers are doing more harm than good: they have degraded the cells they were inserted into without giving you a resolved wall anywhere.

Between that and the target the message is shorter: "Layer coverage 55% on patch 'body' - below the 70% target."

"Resolved wall treatment needs the first cell at y+ of about 1, and nothing in this case sets that: with no boundary layers the first cell height is whatever the mesh gives, and target y+ does not describe it. Check the y+ result control after the run - too far out and this treatment is badly wrong, not slightly."

A warning against Boundary layers, and it is the set-up-time counterpart of the wall-resolution verdict the application reports after a converged run — see The solver log. Target y+ is an input to the layer generator; with no layers there is nothing for it to act on.

Two shorter siblings fire when layers are present and the target contradicts the treatment: "Resolved wall treatment needs y+ of about 1; the target is <value>." and "Wall functions want the first cell centre in the log region, about 30 < y+ < 300; the target is <value>. Consider the resolved treatment."

Previous: The run will not start · Next: The solver log