OpenFOAM® v1812: New and improved pre-processing

New snappyHexMesh directional stretching

In a previous release directional refinement capability was added. This is useful to limit the amount of cells and also to lower the volume change across refinement (2:1 versus 8:1). This latter change can lower the discretisation error. In this release additionally the mesh can be stretched in the given direction to lower the volume change even more. A typical usage

Source code

$FOAM_UTILITIES/mesh/generation/snappyHexMesh/snappyHexMeshDict

Examples

$FOAM_TUTORIALS/mesh/snappyHexMesh/aerofoilNACA0012_directionalRefinement

New leakage detection

With complex geometries it can be easy to have the mesh ’spill out’ of the inside of the geometry. In this release there are two ways of detecting these ’mesh leaks’.

In snappyHexMesh

In snappyHexMesh the keyword locationsOutsideMesh specifies locations where the mesh should not go. In previous releases this would lead to an error message and exit. In the current release it analyses the mesh and determines the shortest path, walking from cell centre to cell centre, between the locationInMesh and the locationsOutsideMesh and writes the result as a sampledSet. This produces a file in a line-based format, e.g..obj in the postProcessing directory which can be loaded into a post-processor. Identifying where the path intersects the geometry is usually a good candidate for the leak.

The algorithm is run during the snappyHexMesh refinement stage so it should be fast in detecting these mesh leaks. The output of the mesh-leak can be in any format supported by the sampledSet framework through the optional setFormat keyword, where the default format is vtk.

Post-processing the mesh using the sample utility

The same algorithm can also be run stand-alone on any mesh through use of the shortestPath sampled set. e.g. removing the visor patch and some patch faces on the back of the motorBike tutorial allows the mesh to flood into the (previously closed) surfaces. These leak paths can be identified using:

Note that the shortestPath sampled set requires at least one field to operate on. In the above example the processorField function object is used to generate a field containing the local processor number.

Source code

$FOAM_SRC/sampling/sampledSet/shortestPath

Examples

$FOAM_TUTORIALS/mesh/snappyHexMesh/motorBike_leakDetection

New Homogeneous Isotropic Turbulence (HIT) initialisation

The decay of homogeneous isotropic turbulence is a standard test for validating turbulence models, but the initialisation can prove difficult. The new createBoxTurb utility, based on the procedure of Saad et al., makes this process straightforward by:

• creating the initial box mesh with cyclic patches
• creating an initial velocity field according to a user-specified energy content, optionally in parallel

The following example compares the computed energy spectrum for a 256x256x256 mesh against the input spectrum of Comte-Bellot and Corrsin:

The resulting decay is shown below:

Source code

$FOAM_UTILITIES/preProcessing/createBoxTurb

Examples

$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/decayIsoTurb

References

Saad, T., Cline, D., Stoll, R., Sutherland, J.C. ”Scalable Tools for Generating Synthetic Isotropic Turbulence with Arbitrary Spectra” AIAA Journal, Vol. 55, No. 1 (2017), pp. 327-331.
Comte-Bellot G. and Corrsin S. ”Simple Eulerian time correlation of full- and narrow-band velocity signals in grid-generated, ’isotropic’ turbulence” J. Fluid Mech. Vol. 48, part 2 (1971), pp. 273-337

Improvements for topo-sets and searchable surfaces

In this version, existing cell/face/point selection mechanisms have been made more consistent with each other and with their searchableSurface counterparts. Their expected inputs are now also consistently documented in the API guide.

Where possible, support for multiple selections has been added e.g. accept patches, sets and zones instead of just patch, set and zone. This is a user convenience, but also a performance improvement for topoSet since it avoids intermediate writes.

The dictionary inputs for topoSet has been given a more compact, user friendlier syntax and the sourceInfo entry is now optional. For example,

versus the longer input style:

The searchable surfaces, which are often used in snappyHexDict are available with shorter names as an alternative to the longer names.

• New: box, cylinder, sphere …
• Longer: searchableBox, searchableCylinder, searchableSphere …

Improved input dictionary robustness

As a text-driven code, setting and manipulating dictionary values lies at the heart of the OpenFOAM user experience. A focus for this release has been to harden the dictionary input, providing a more robust interaction when detecting and localizing input errors.

This means that some of your existing input dictionaries may have previously undetected syntax errors, which will now be detected and flagged as errors.

If you discover a false positive, i.e., it is incorrectly detected as an error please raise a gitlab issue.

Here is a small collection of the types of errors that could be encountered and what type error message or warning you may expect.

• We addressed the case of a missing ; on an entry in OpenFOAM v1806 which are now detected by the new guarded read dictionary methods:

  dict
  {
      key1 true   // oops no trailing ';'
      key2 "<case>/filename";
  }
  
• When a guarded read such as dict.get<bool>(key1) or dict.lookupOrDefault(key1, true) is used by the programmer, this type of error message will be provoked:

  --> FOAM FATAL IO ERROR:
  Entry 'key1' has 2 excess tokens in stream
  
      3(true key2 "<case>/filename")
  
• When the missing ; is the last dictionary entry, the guarded reads will not find it, but it will already have been discovered while reading in the dictionary read.

  dict
  {
      key missing ending
  }
  

  Results in two warnings, and one error:

  --> FOAM Warning :
      Reading "test.dict" at line 20
      Too many closing '}' ... was a ';' forgotten?
  --> FOAM Warning :
      Reading "test.dict" at line 24
      Imbalanced brackets
  
  --> FOAM FATAL IO ERROR:
  "ill defined primitiveEntry starting at keyword 'key'
  on line 19 and ending at line 24"
  
• This release also detects if there are too many closing ‘}‘ and the dictionary reading stops prematurely, e.g.

  dict1
  {
      key1 value1;
      key2 value2;
  }
  
  }  // oops extra stray '}'
  
  dict2
  {
      key1 value1;
      key2 value2;
  }
  

  The dictionary reading stops when it encounter the stray ‘}‘, since this normally signals the end of a dictionary. In previous versions this would have meant that dict2 above was never read at all. In OpenFOAM-v1812, this will now be flagged as an input error:

  --> FOAM FATAL IO ERROR:
  Unexpected '}' while reading dictionary entry
  file: test.dict at line 23.
  
• The other extreme would be forgetting to close the dictionary entry. The user may have forgotten it, the file was somehow truncated, or the file was automatically generated but something went wrong in the process.

  dict
  {
      key1 value1;
      key2 value2;
  
  // oops no trailing '}'
  

  This now causes this type of error message:

  --> FOAM FATAL IO ERROR:
  Unexpected EOF while reading dictionary entry
  file: test.dict at line 26.