OpenFOAM provides a collection of ~200 application programs which each carry out a specific task in computational fluid dynamics (CFD). Solver applications, or “solvers”, compute the fluid dynamics and, optionally, heat transfer, thermodynamics, reactions and other complex physics. Utility applications undertake other tasks within a CFD workflow, e.g. mesh generation, case initialisation and further processing of solution data. Applications get most functionality from 100+ OpenFOAM libraries, including models for transport, turbulence, thermodynamics, chemical reactions, particle flows, surface films etc.
Models on Demand
Left unchecked, the number of solvers would grow exponentially to include the various combinations of models required by OpenFOAM’s users. Thankfully the OpenFOAM core maintenance team at CFD Direct consolidates solvers to prevent this. For example, during maintenance work on the surface film functionality, the team implemented film calculations within an fvOption named VoFSurfaceFilm which could be used in simulations running compressibleInterFoam. This meant compressibleInterFilmFoam, a duplicate solver with additional film modelling introduced in OpenFOAM v5, could be removed. The team then wondered whether they could create fvOptions for other models to remove more solvers.
Redesign of Models and Constraints
fvOptions were introduced in OpenFOAM v2.2 in 2013 “for any physics that can be represented as sources or constraints on the governing equations.” Their purpose from the outset was to manipulate equations in the solvers in two ways: 1) providing source terms to equations in the solver; and, 2) applying constraints to the solution of an equation. The API (application programming interface) was not designed for large models and it was bloated because the functions applying the constraints did not do anything for source fvOptions, and vice versa.
Therefore in March 2021, the team at CFD Direct introduced fvModels and fvConstraints as a “rational separation of fvOptions between physical modelling and numerical constraints”. The naming of fvModel reflected the ambition to support models which involve complex calculations and their interaction with the main solver, rather than simply source terms.
Interface and State
One clear distinction between fvModels and fvConstraints relates to “state”, i.e. stored model data such as fields, coefficients, etc. fvModels holds internal state which evolves by either calculating algebraic expressions and/or solving additional transport equations, and through interaction with the solver. The interface in the solver (example, right) provides the correct()function to evolve state and source()to influence the governing equations, e.g. momentum conservation.
fvConstraints do not hold an evolving internal state but instead simply apply constraints to the solution of equations. The constrain()function applies the constraints both to the matrix equation (UEqn) prior to solution and then afterwards to the solved field (U).
New Models and Constraints
The new design encouraged the development of some new fvModels. They include heatTransfer and heatSource which provide source terms for heat transfer to an ambient temperature and heat as a total power or power per unit volume, respectively. These fvModels target common use cases directly and are easier to configure than a generic source fvOption. Similarly, a new limitPressure fvConstraint replaces the optional pressure limiting previously built into solvers. This is more consistent with constraints on other fields, e.g. limitVelocity and limitTemperature, which is more readily extensible to other fields.
Flow Switches
New clouds and surfaceFilm fvModels provide particle and film modelling with coupling to the continuum within general solvers. The reactingFoam solver can then replicate the functionality of reactingParticleFoam, reactingParcelFoam, sprayFoam and simpleReactingParticleFoam, which have been deprecated. The buoyantReactingFoam solver reproduces buoyantReactingParticleFoam and fireFoam, which are also deprecated. Overall, the total number of solvers has reduced from 62 to 53 in the past year.
An additional hydrostaticInitialisation switch to initialise hydrostatic pressure was required to deprecate fireFoam. The general solvers include new models, thermophysics and flow switches to allow users to deactivate those components of a simulation. This approach to solver design, with optional models and switches, is consistent with our OpenFOAM Training which builds CFD competency by designing solutions in small steps from prototype to production and packaging.