In 2016 we published a guide for Useful Tools in OpenFOAM with tools we first released in OpenFOAM v4. The tools included the post-processing CLI and template cases, and applications such as foamDictionary. We extended the article following the release of new tools such as TAB completion in OpenFOAM v5 and scripts such as foamGet and foamInfo in OpenFOAM v6. Further additions came along in later versions, but OpenFOAM v11 has brought some significant changes and additions described below, to provide compatibility with its modular solvers, while maintaining backward-compatibility with application solvers.
The foamToC utility
OpenFOAM is mature software for computational fluid dynamics. It includes functionality to simulate problems with multiple regions, physics, fluid phases and species, numerical methods and sub-domains (when running in parallel). With so much functionality, it can be challenging to find information about a library, application, model, option, setting, control, parameter, etc. In OpenFOAM v5 we introduced -list... options to solvers to list available models in OpenFOAM. These options included: -listScalarBCs and -listVectorBCs to list boundary conditions; -listFvModels and -listFvConstraints to list fvModels and fvConstraints; -listFunctionObjects for function objects (see below); and -listMomentumTransportModels to list momentum transport models, e.g. turbulence models.
One drawback of the -list... options is their limitation to a narrow set of models. For OpenFOAM v11, we created foamToC , a general utility for printing a “Table of Contents”. It includes equivalent options to most of those described above, dropping the list prefix, i.e.-scalarBCs, -vectorBCs, -fvModels, -fvConstraints, and -functionObjects. It includes a -solvers option to list all the solver modules in v11. However, the real power of foamToC is provided by the more general options described below.
Let us imagine a user is working on a case that contains a viscosity model named BirdCarreau. They might need to find the other models of the same family. With foamToC, they can find the table used at run-time which contains their model of interest using the -search option as follows.
foamToC -search BirdCarreau
The command produces the following output.
BirdCarreau is in table
generalisedNewtonianViscosityModel libmomentumTransportModels.so
The output shows the table in the first column, with the second column showing the library to which it belongs . The user can then interrogate the table using the -table option to reveal the other models in the family.
foamToC -table generalisedNewtonianViscosityModel
For further information, see OpenFOAM User Guide, The foamToC utility.
TAB Completion and foamInfo
In OpenFOAM v5 we introduced Bash (TAB) Completion to enable users to complete terminal commands and their arguments easily using the TAB key. The completion for foamToC is very powerful to explore OpenFOAM functionality. Let us imagine a user is looking for RAS models and they begin typing the following.
foamToC -table RAS[TAB][TAB]
The command line offers the main table RAS, followed by a set of sub-tables beginning RAS. The user could then complete one of the sub-tables, e.g. with the following example.
foamToC -table RASincompressibleMomentumTransportModel
This lists the well known models such as kEpsilon, kOmegaSST, etc.
In OpenFOAM v6 we introduced the foamInfo script which provides information and examples relating to a subject that the user provides. The subject can relate to: models, including boundary conditions and packaged function objects; applications; and, scripts. The script now includes TAB completion on the subject word, which initially provides over 1000 suggestions. Let us imagine the user wants information on the kEpsilon turbulence model, then they can quickly type the following.
foamInfo kEp[TAB]
which completes to the following
foamInfo kEpsilon
They can quickly hit [ENTER] and view information with a description and examples (selecting option 2).
For further information, see OpenFOAM User Guide, The foamInfo utility.
Post-Processing and the foamPostProcess utility
In OpenFOAM v4 we created bespoke preconfigured files for popular post-processing tasks in OpenFOAM. The files launched function objects which contained a variety of general coded functionality (which had been part of OpenFOAM for some time). We recoded all post-processing functionality into function objects and created “packaged” function objects for them all. The post-processing can be performed during a simulation by “plugging” it into the case, or it can occur once the simulation is complete.
The number of function objects has increased to approximately 100 today. The function objects can be listed using foamToC as follows.
foamToC -functionObjects
In OpenFOAM v11 we created the foamPostProcess utility to work with solver modules instead of the postProcess utility introduced in v4. The advantage of foamPostProcess is that it loads in the solver module, typically specified in the controlDict file. Unlike the postProcess utility, it can access objects from the database which the solver constructs, similar by default to running a solver application with the -postProcess option.
The packaged function objects can be listed using foamPostProcess, as postProcess does, with the -list option as follows.
foamPostProcess -list
The main command line options for foamPostProcess are the same as for the postProcess utility, e.g. the -func option selects a specific packaged function, e.g.
foamPostProcess -func "patchFlowRate(name=outlet)"
For further information about foamPostProcess and post-processing in general, see OpenFOAM User Guide, Post-Processing CLI.
The snappyHexMeshConfig utility
In OpenFOAM v4 we introduced template cases to provide a convenient way to set up and start a new simulation. They include simplified configuration files for generating a mesh with snappyHexMesh, with placeholder entries for users to populate for their specific case. For example, the background mesh specified through the blockMeshDict file requires the minimum and maximum bounds to be specified, and the mesh density, for a single rectangular block of cells. The snappyHexMeshDict file requires the surface geometry files to be included and equivalent entries in the surfaceRegions section of the file.
For OpenFOAM v11 we have created snappyHexMeshConfig, a utility which preconfigure input files for meshing with snappyHexMesh, including the blockMeshDict, surfaceFeaturesDict and snappyHexMeshDict files. Starting from a standard OpenFOAM case, this utility locates surface geometry files, e.g. OBJ, STL format, in the constant/geometry directory. It writes out the configuration files based on assumptions which can be overridden by options on the command line.
The utility processes the surface geometry files, attempting to anticipate their intended purpose, trying in particular to recognise whether the domain represents an external or internal flow. If there is a surface which is closed, and is either single or surrounds all other surfaces, then it is assumed that it forms the external boundary of an internal flow. This assumption is overridden if the bounds of the background mesh are specified using the -bounds option and they are more than 50% larger than the surface bounds.
The utility identifies named inlet and outlet regions in surfaces or the user can specify them with -inletRegions and -outletRegions options. Surfaces which are contained within the domain, which do not surround or intersect other surfaces, are assumed by default to be wall patches. Any closed surface which surrounds another (but not an external surface) is used to form a cellZone within the mesh. Users can identify specific surface types using the -cellZones, -baffles and -rotatingZones options.
The bounds and mesh density of the background mesh are automatically calculated, but can be overridden by the -bounds and -nCells options. Patches can be configured in the background mesh, e.g. for an external flow, using options such as -xMinPatch, -xMaxPatch and -defaultPatch. A special -cylindricalBackground option generates a cylindrical background mesh, oriented along the z-axis along x = y = 0. Numerous options exist for most of the configuration entries in the snappyHexMesh file. Users can either run snappyHexMeshConfig and then modify the resulting configuration files, or include options so the generated configuration files require no further modification.