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
// Dummy uniform refinement
levels ((10000 0));
// Directional refinement
// - for all cells with uniform level 0-1
// - do one split in y and z direction.
levelIncrement (0 1 (0 1 1));
// Directional expansion-ratio smoothing
smoothDirection (1 0 0);
// Smoothing of expansion ratio
// Smoothing of positions
- Source code
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 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.
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:
insidePoints ((3.0001 3.0001 0.43))
outsidePoints ((1 0 1.3));
// Colour the leak path by the processor ID
- Source code
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
- 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
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,
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 …
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:
key1 true // oops no trailing ';'
- 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
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
--> 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
} // oops extra stray '}'
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.
// 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.