OpenFOAM v13, produced by CFD Direct and released via The OpenFOAM Foundation, is the best version of OpenFOAM today. It is not only the best version of OpenFOAM released by the Foundation, but OpenFOAM from the Foundation is also the best, compared to other variants. The Foundation OpenFOAM has been better for some years now, certainly since OpenFOAM v11 in 2023 when there was “clear water” between it and others, as one commentator put it.
What makes OpenFOAM v13 the Best?
What do we mean by “the best”? In 2018 we produced a strategy for the sustainable development / maintenance of OpenFOAM which was presented at The OpenFOAM Open Day in September that year. We identified the critical needs of users — availability, usability, robustness and extensibility – as the key criteria that determine quality. We focussed on redesign, repair and “publishing” to meet these critical needs, which has been the driver of quality that made Foundation OpenFOAM the best.
Under “publishing”, we created numerous useful tools (and here) to improve usability. We improve availability through comprehensive OpenFOAM download instructions, with sensible options for OpenFOAM on Windows and OpenFOAM on macOS, and a dedicated OpenFOAM download repository. Our repair work centres around the OpenFOAM Issue Tracking site. It showed our progress in resolving issues, and enabled us to identify critical areas for redesign.
Redesign: Finding Solutions (➤) to Problems (!)
It is really the amount of major redesign work performed by CFD Direct which makes the Foundation OpenFOAM the best. By redesigning a component, fundamental problems can be eradicated, eliminating a recurrence of issues (bugs) for a significant improvement in robustness. Good design transforms an inflexible structure into a code component that is easy to extend. A structure with well-designed code interfaces inevitably delivers an intuitive user interface and a clear improvement in usability. With redesign you get improvements to all three: usability, robustness and extensibility.
Below are examples of major developments and code redesigns. For each one we summarise the problems (denoted by !) and the solution (denoted by ➤). For more information about each piece of work, follow the links provided. If you want to learn about these developments, come on our OpenFOAM Training.
Solvers (v11, 2023)
- Proliferation of too many, inconsistent solvers with a lot of duplication; difficult to select and to extend; inflexible for cases with multiple mesh regions.
- Modular solvers, developed as classes, minimising duplication, easier to extend, few (<20) in number, so easier to select; completely flexible for multiple regions since different modules can run on different regions.
Coupling disconnected mesh regions (v10, 2022)
- Arbitrary mesh interface (AMI) does not conserve mass, causing unstable and inaccurate solutions; ACMI for non-matching interfaces rarely worked at all; responsible for a cluster of unresolvable issues.
- Non-conformal coupled (NCC) interface, which conserves mass providing robust, accurate solutions which extends effortlessly to non-matching interfaces.
Particles (v13, 2025)
- The particle, or Lagrangian, modelling stored data (e.g. diameter, velocity) with particles themselves; the code worked by deriving particle types with specific data, much of which could be unused; adding an additional piece of data to particles required a new particle type, making it highly inflexible and difficult to extend.
- Entirely new Lagrangian implementation (65% completed) which stores data as fields, making it consistent with the underlying design of OpenFOAM and making all modelling easily extensible since fields can be simply added.
MULES (v2.3, 2014, then v13, 2025)
- The VoF method solves one or more phase-fraction advection equations; it is a huge challenge to maintain bounded solutions that are sufficiently accurate.
- The MULES limiter was created by Henry Weller in 2006; solutions were accelerated by a semi-implicit approach in 2013; while this was generally successful, changes to MULES in 2025 made it guarantee boundedness and accelerated solutions significantly on complex problems, e.g. with the multiphaseEuler solver.
Mesh zones (v13, 2025)
- Zones that describe regions of a mesh were fixed in number, could not change during a simulation and could not overlap; tools involving zones, e.g. refineMesh, were difficult to use; topoSet, the main tool to generate zones and sets (two things which broadly do the same thing) is unpleasant to use.
- Dynamic zones which are generated on demand, with a clean consistent structure; tools that use zones can generate them on-the-fly, making those tools easier to configure; the lousy topoSet is replaced by a clean, user-friendly createZones tool.
Meshing with snappyHexMesh (v11, 2023)
- Configuration of input files for meshing was a long and difficult exercise due to both the large number mandatory settings required and general operational parameters.
- The snappyHexMeshConfig utility which write the configuration files, mostly automatic; leaves the user to specify only a few settings either by editing the relevant file(s) or by using some of the many command line options.
Dynamic meshes (v11, 2023)
- Grouped motion and topology (refinement/unrefinement) and only permitting one or the other; no parallel load-balancing with refinement; cases fail beyond a modest level of mesh deformation.
- Redesign of dynamic mesh functionality with a separate interface for topology and motion; with a new mesh distribution framework that works closely with the topology changes; mesh-to-mesh mapping to overcome the mesh deformation issue, enabling simulation of internal combustion engines.
Models and constraints (v9, 2021)
- Configurable models, e.g. thermal radiation, and numerical constraints, e.g. fixing temperature in a region of the domain, were part of the same fvOptions code framework; interface to solvers was bloated and ineffective for large models.
- Separate fvModels and fvConstraints code frameworks, each responsible for configurable models and numerical constraints, respectively; each framework has its own interface with solvers, making them easier to extend and use.
Liquid film (v11, 2023)
- surfaceFilmModels library which included sub-modelling that was specific to films and duplicated standard modelling, e.g. thermodynamics; solved for film height, on a mesh of one cell thickness, which did not conserve mass for films on curved surfaces; required specialist solver applications to provide coupling between the film and solid and/or fluid.
- film and isothermalFilm modular solvers that use standard modelling and solve for a phase fraction to conserve mass; couples with solid and/or fluid regions like other multi-region solutions, with the flexibility of choice of modular solvers.
Transport modelling (v8, 2020)
- Inconsistent calculation of transport fluxes between the solution, boundary conditions and data processing; confusing, inflexible structure to develop new models, e.g. viscoelastic models were part of turbulence modelling.
- Dedicated momentum and thermophysical transport model libraries with interfaces that ensure consistency throughout the code; easier to extend to more complex transport models.