OpenFOAM and the case for a GUI

OpenFOAM is an open-source computational fluid dynamics toolbox, released under the GPL and in continuous development since the 1990s. It is not a cut-down or academic code: it solves incompressible and compressible flow, multiphase and free-surface problems, combustion, conjugate heat transfer, rotating machinery and more, with a mature finite volume discretisation and solid parallel scaling.

It is used in industry and in research, and results from it are published and defended. If you are wondering whether the solver underneath an open-source CFD stack is good enough for real engineering, that question was settled a long time ago.

OpenFOAM’s interface is the filesystem. A case is a directory tree, and setting one up means writing dictionaries — structured text files — by hand:

• 0/ holds one file per field (velocity, pressure, turbulence quantities), each listing a boundary condition for every named patch in the mesh.
• constant/ holds the mesh and the physical properties, plus the turbulence model selection.
• system/ holds the run control, the discretisation schemes, and the linear solver settings — controlDict, fvSchemes, fvSolution, and snappyHexMeshDict if you are meshing.

Meshing is its own undertaking. snappyHexMesh is capable and controlled by a dictionary with a great many interacting settings — refinement levels, feature edges, surface and volume refinement regions, boundary layer parameters that silently fail to be inserted if the underlying cells are not suitable.

Nothing about this is unreasonable, and it is superb for reproducibility and automation: a case is text, so it diffs, versions and scripts. But the learning curve is real and it is front-loaded. The common experience is not that OpenFOAM gives a wrong answer; it is that a competent engineer spends a fortnight before getting any answer at all, and cannot tell whether the silence is a setup error, a mesh failure or a genuinely diverging run.

A graphical front end does not make the solver better — it is the same solver. What it can do is remove the failure modes that have nothing to do with fluid dynamics:

• Knowing which fields a case needs. The set of files in 0/ depends on the turbulence model and physics you chose. A panel that knows the model can write exactly the right fields, instead of leaving you to discover a missing one from a runtime error.
• Patch-by-patch boundary conditions. Setting an inlet on a named surface, rather than editing the same patch name across six files and keeping them consistent by hand.
• Seeing the mesh before you solve. Quality metrics and y+ estimates in front of you, rather than inferred after a run has already been wasted.
• Watching the run. Residuals, monitored quantities and problems plotted live, so a diverging case is obvious in the first minute rather than the fortieth.
• Getting results out. Surfaces, slices, contours, streamlines and plots without a separate post-processing tool and a second learning curve.

The legitimate objection to front ends is that they hide the decisions that matter. A tool that quietly picks a turbulence model, silently adjusts your schemes, or presents a converged-looking result without showing you the residuals has not made CFD easier — it has made it harder to know when you are wrong.

The tests worth applying to any front end:

• Can you see the case it generated, and is it a normal OpenFOAM case?
• Can you still run it from the command line, on a cluster, without the GUI?
• Does it show you convergence honestly, including when it is bad?
• Does it tell you what it assumed on your behalf?

If a front end fails those, you have swapped a steep learning curve for a dependency you cannot audit, which is a worse trade for engineering work.

SHD Sim is a desktop application built around OpenFOAM as its solver. Geometry import, meshing with refinement regions and boundary layers, physics and materials, per-patch boundary conditions, running with live residuals, post-processing and an A4 report — in one window, on Windows, with nothing to compile.

It is deliberately built to pass the tests above. The case it writes is a normal OpenFOAM case on disk. The same run can be driven from batch flags in a script. The convergence plots show what actually happened, and the report states the threshold behind each verdict rather than a pass badge.

If you already know OpenFOAM, run on Linux, script everything and live in a terminal, a GUI adds little and you should keep your workflow. The same is true if you need a solver or a custom boundary condition that only exists as source you intend to modify — that is exactly what an open codebase is for.

A front end earns its place when the bottleneck is setup rather than physics: when you need CFD occasionally rather than daily, when the person who has to run it is a design engineer rather than a CFD specialist, or when the result has to be handed to somebody else in a form they can check.