OpenFOAM® v1806: New and improved pre-processing

OpenFOAM® v1806: New and improved pre-processing


New solver dry-run options

Debugging large cases can be challenging, particularly when working in cluster environments where users add their jobs to batch queuing systems. A typical iterative process to correct errors in input dictionaries can lead to significant delays prior to running the case.

The new -dry-run option available to solver applications attempts to make the process of correcting input errors straightforward by replacing the mesh with a simplified variant that preserves the main case characteristics, e.g. boundary conditions, mesh extents, zone information:

simpleFoam -dry-run

On execution, the solver application runs a single time step. If any input errors are reported, e.g. missing or badly formed entries, these can be easily identified, giving more confidence that the full case will run successfully.

Many post-processing tools such as function objects perform their tasks at calculation write times. The new -dry-run-and-write option instructs the solver to perform a single time step and perform a write operation, e.g.

simpleFoam -dry-run-and-write

Note that these are applied to the simplified mesh and values may not be representative for the case. To avoid conflict with any existing postProcessing directory the output is written to the postProcessing-dry-run directory.

The tool operates in two modes:

  • with mesh: mesh boundary information is extracted from the constant/polyMesh/boundary file; domain extents are set according to the mesh points
  • without mesh: the simplified mesh is constructed using the patch names provided in a field file. However, this will limit the effectiveness of the tool:
    • all patched will use a wall type by default
    • all patches must be defined using the same patch names across all field files, e.g. care must be taken when using regular expressions
    • the simplified msh bounds are set ’to a large value’

Known limitations

  • Coupled patches are currently ignored
  • Not available to multi-region solvers, e.g.chtMultiRegionFoam

Improved dictionary robustness

Several changes have been made to assist with detecting ill-formed dictionary input, with further changes slated for the v1812 release.

This type of error often arises when a trailing ’;’ has been omitted.

    keyword  <entry with missing semi-colon>

The change will detect that the entry terminated with a ’}’ but had not started an initial ’{’ - in this case since the trailing ’;’ was forgotten.

This change will flag the following type of problems of primitive entries:

  • mismatches:

    keyword  mismatch ( set of { brackets ) in the } entry;
  • underflow too many closing brackets:

    keyword  too many ( set of ) brackets ) in ) entry;
  • a missing semi-colon on an sub-dictionary entry will be flagged as ’underflow’, since it parses through the ’}’ but did not open with it.

New string expansion shortcuts

A new concise format is now available to specify common case locations:

Short-form Equivalent
<etc>/” as per foamEtcFile
<case>/” ”$FOAM_CASE/”
<constant>/” ”$FOAM_CASE/constant/”
<system>/” ”$FOAM_CASE/system/”

These can be used in fileName expansions to improve clarity and reduce typing.

Since these short forms correspond to absolute file locations, they only have mean when they occur at the start of the file name.

Previous code:

#include "$FOAM_CASE/constant/reactions"
#include "$FOAM_CASE/system/blockMeshDict"

With shortcuts:

#include "<constant>/reactions"
#include "<system>/blockMeshDict"

Note that expansions with $FOAM_CASE will continue to work without any change, but the new forms are shorted and easier to read.

Improved mapFieldsPar performance

A new method to determine the parallel processor map has been added to the mapFieldsPar utility. Depending on the quality of the parallel decomposition, the axis-aligned bounding box (AABB) tree method used in earlier versions could generate a map that sent all data to a local processor, leading to a large processor loading imbalance and potential failure.

The new option creates the map based on a local level of detail (LOD), selected via the optional procMapMethod keyword:

mapFieldsPar -procMapMethod LOD <other options and arguments>

Initial tests have suggested a reduction of the order 15-20% in execution time. For backwards compatibility, if the procMapMethod option is not provided the AABB option is chosen.

snappyHexMesh New directional refinement

snappyHexMesh now supports additional directional refinement inside refinementRegions. This is done through the optional keyword levelIncrement inside the refinementRegions dictionary. The mode keyword decides which side of the refinement geometry is refined. Any omni-directional refinement (through the level) keyword is performed first, followed by selectively splitting cells in a given direction. e.g.

        mode        inside;

        // Dummy uniform refinement
        levels      ((10000 0));

        // Directional refinement
        //  - for all cells with uniform level 0-1
        //  - do one split in y and z direction. Note:the resulting mesh is
        //    no longer compatible with e.g. dynamic
        //    refinement/unrefinement.
        levelIncrement  (0 1 (0 1 1));

In below figures the effect of the additional refinement is shown on a simplified airfoil shape, without directional refinement:


and with directional refinement


The limitations are

  • the refinement is only in regions - there is no surface-based equivalent
  • the starting mesh has to be coordinate axis aligned (you can move it afterwards using e.g. transformPoints)
  • the resulting mesh will be incompatible with dynamic refinement/unrefinement.

Source code