OpenFOAM® v1906: New and improved pre-processing

OpenFOAM® v1906: New and improved pre-processing


Conditions in dictionaries

Dictionaries now support conditionals using #if or #ifeq. A typical use might be to support different versions of the code in a single dictionary or different input for different applications.

Different input for different applications

As an example trying to use the new ’exactDistance’ wall-distance calculation. It currently requires the hierarchical decomposition method selected in the decomposeParDict dictionary. However for actual decomposition it is preferential to run with e.g. scotch

numberOfSubdomains 10;
#ifeq $FOAM_APPLICATION decomposePar
    method scotch;
    method hierarchical;
        n  (5 2 1);

Different input for different OpenFOAM versions

The following example shows how the conditional statements can be used to set different keywords for different code versions:

    // Get version number as dictionary entry. This is only so
    // the follow-on test can use dictionary expansion
    versionNo $FOAM_API;
    // Do comparison (using dynamic code compilation)
    #if #calc "$versionNo<1812";
        version "pre-1812";
        version "post-1812";
    version "Unofficial version of OpenFOAM";

Running this example using foamDictionary prints version post-1812 in v1906 and version pre-1812 in e.g. v1706.

Source code

snappyHexMesh : dry-run operation

snappyHexMesh has been extended with dry-run functionality. It will:

  • check all non-optional dictionary entries in snappyHexMeshDict. Any errors/warnings are collated.
  • check existence of input geometry, i.e. surface and features
  • check whether the initial mesh is coordinate axis aligned (this is allowed so is a warning)
  • check whether the geometry is inside the bounding box of the initial mesh (warning only)
  • check whether the location(s) in/outside mesh are inside the initial mesh
  • output the expected cell size from all the refinement levels and the initial cell size
  • output a ’guesstimate’ for the number of cells. This takes into account the refinement levels and location(s)InMesh but misses out on feature refinement and layers.

A typical output might contain:

--> FOAM Warning :     motorBike bounds not fully contained in mesh
        bounding box      : (-0.291665 -0.350289 -4.232e-05) (1.75115 0.332267 1.35152)
        mesh bounding box : (-5 -4 0) (15 4 8)

Cell size estimate :
    Level  0 : 1
    Level  6 : 0.015625

Voxellating initial mesh : (320 128 128)

Voxel refinement :
    Initial                      : (5242880)
    After removing outside cells : 1(0)
    After surface refinement     : 6(0 0 0 0 0 3146)
    After keeping inside voxels  : 6(5239395 0 0 0 0 3146)
    After shell refinement       : 6(5116160 0 0 0 123574 3146)
Estimated cell count : 149991

Source code

snappyHexMesh : memory optimisation

snappyHexMesh performs frequent load-balancing using the redistributePar framework. This requires all processors to know how many cells to receive. In previous versions this information was distributed using a global broadcast. In this version only the local amount of cells-to-be-received is communicated, giving large memory savings from about 4000 cores onwards.

Source code
Investigation and fix by Y. Inoue at RIST

snappyHexMesh : Relaxed patch regioning

By default snappyHexMesh will preserve edges between regions as much as possible. If a cell has two or more coplanar faces on different patches these will not get merged so as to preserve the connecting mesh edge. However, this behaviour can interfere with layer addition since it lowers the mesh quality.

In this release there are two new optional controls in snappyHexMeshDict:

  • mergePatchFaces : default true
  • mergeAcrossPatches: default false

If mergePatchFaces is false it will not do any merging of patch faces. This will keep the mesh after refinement and snapping compatible with refinement/unrefinement.

If mergePatchFaces is true (default) it will look at mergeAcrossPatches: if this is false (default) it will not merge faces if they are on different patches.

The effect of this setting can be be seen when meshing a simple triangulated sphere with two regions


On the right is the default behaviour where each face is in the patch corresponding to the surface region. This preserves the mesh edge between the surface regions. On the left is the effect of enabling mergeAcrossPatches where faces cross the feature edge. This will improve the geometric mesh quality at the cost of less accurate geometric conformation to give better layer coverage:


Source code