OpenFOAM® v2012: New and improved pre-processing


snappyHexMesh: new hybrid layer input

Layer thickness can be specified as either absolute or relative (to the bulk cell size) sizes using the relativeSizes keyword. Using relative sizes, all thicknesses are multiplied by the average size of the cells surrounding each point.

This release adds a new option to specify the near-wall layer using an absolute thickness, e.g. to obtain a desired  +
y   \relax \special {t4ht= at the first wall layer, and a relative thickness for the final layer closest to the bulk to minimise mesh distortion.

The behaviour is enabled using the new thicknessModel keyword that can take the value of:

  • firstAndOverall;
  • firstAndExpansion;
  • finalAndOverall;
  • finalAndExpansion;
  • overallAndExpansion; or
  • firstAndRelativeFinal.

The selection determines which of the thickness controls need to be present:

model firstLayer finalLayer overall expansion
firstAndOverall V . V .
firstAndExpansion V . . V
finalAndOverall . V V .
finalAndExpansion . V . V
overallAndExpansion . . V V
firstAndRelativeFinal V V . .

In this version all parameters can be prescribed on a per-patch basis, where for points on multiple patches, the final wanted dimensions are the minimum of the individual patch settings.

A typical input is shown in the tutorial:

    // Are the thickness parameters below relative to the undistorted
    // size of the refined cell outside layer (true) or absolute sizes
    relativeSizes false;

    thicknessModel firstAndRelativeFinal;

    firstLayerThickness 0.1e-3;

    finalLayerThickness 0.5;


Source code

SnappyHexMesh: automatic refinement in small gaps

snappyHexMesh provides optional automatic refinement in small gaps, enabled using the gapMode and gapLevel keywords. The gapMode specifies on which side of the surface to apply the algorithm, and gapLevel the wanted level. It is applied to the cells described by a refinementRegion.

Distance based gap refinement

In previous versions the selection could only be inside or outside a surface; in this version a distance-to-surface selection can also be used:

        mode        distance;

        // Distance and minimum uniform refinement level
        levels      ((3.0 0));

        // If cells
        // - have level 0..9
        // - and are in a gap < 3 cell sizes across
        // - with the gap on the inside ('inside'), outside ('outside')
        //   or both ('mixed') of the surface
        // refine them
        gapLevel    (4 0 10);
        gapMode     mixed;
Note: the levels selection is a single entry when used in distance mode.

Disabling self-proximity refinement

Using the previous example, refinement can be disabled due to close gaps on the same surface by the gapSelf:


    gapLevel    (4 0 10);
    gapMode     mixed;
    gapSelf     false;
This setting is used to ensure that only gaps between different surfaces are detected.


Source code
More information
See Issue #1463

snappyHexMesh: delete small regions

snappyHexMesh can occasionally create multiple, disconnected regions for a cellZone when generating boundary faces, i.e. when the keyword faceType is set to baffle or boundary. These regions may be desirable and get connected at a later stage, e.g. using of the cyclicAMI patches, but in many cases their existence may lead to numerical problems.

These cell regions can be removed as a post-processing step using topoSet with the regionToCell source, followed by deletion step using subsetMesh.

To simplify this workflow, the same functionality is now available in snappyHexMesh, triggered by the new minCellFraction keyword in the castellatedControls section of your snappyHexMeshDict file:

//- Any region smaller than below fraction of the overall (on a per-zone basis) gets removed.
//  Default is 0 (= disabled)
minCellFraction 0.001;

Once enabled, additional output is generated of the form:

Deleting region 2 (size 172) of zone size 12344517

Source code

snappyHexMesh: consistent layer extrusion

snappyHexMesh can add extrusion layers to existing meshes. In previous versions problems arise in parallel when the end of a patch to extrude coincides with a processor interface, leading to collapse of the added layers.

In the test case below, the mesh (generated using blockMesh) has a patch to be extruded on the top left. By rotating the mesh before using hierarchical decomposition this patch is exclusively on processor0:


In previous versions layers are truncated at the interface with processor 1:


In this version the information to extrude the side edge into faces can also come from remote, connected edges, yielding the expected layers:


Source code

extrudeMesh: new polyLine option

The new polyline extrusion model employs the functionality of blockMesh edges to define the extrusion path.

extrudeModel polyline;

In the figure below it is used to extrude a triangular inlet patch:


This was created using the following polylineCoeffs with vertices and edges entries:

    vertices 10
        ( 0 0 0.05 )
        ( 0 0 0.75 )
        ( 0 -0.3 1.05 )
        ( 0 -0.7 1.05 )
        ( 0 -1 1.35 )
        ( 0 -1 1.75 )
        ( 0.3 -1 2.05 )
        ( 0.826794919 -1 2.05 )
        ( 1.08660254 -1 1.9 )
        ( 1.5 -1 1.183974596 )

    edges 9
        line 0 1
        arc  1 2 ( 0 -0.087867966 0.962132034 )
        line 2 3
        arc  3 4 ( 0 -0.912132034 1.137867966 )
        line 4 5
        arc  5 6 ( 0.087867966 -1 1.962132034 )
        line 6 7
        arc  7 8 ( 0.976794919 -1 2.009807621 )
        line 8 9

    toleranceCheck  1e-6;

Source code
Contribution by Ivor Clifford (Paul Scherrer Institut)

blockMesh: improvements

Extended -write-vtk option

When using blockMesh with the -write-vtk option, local orientation vectors are included that can help when designing/debugging blockMesh layouts.


Defining curved edges

The arc specification for edges has been extended to support a specification using an origin. In most cases it is more natural to express an arc in terms of its end points and centre instead of end points and a point on the curve. It also greatly cuts back on the need for a calculator when creating a blockMesh with arcs!

An example of the new style, with the origin:

    arc  0  5 origin (0 0 $zmin)
    arc  5 10 origin (0 0 $zmin)
    arc  1  4 origin (0 0 $zmin)
    arc  4  9 origin (0 0 $zmin)

compared to the traditional style, using a mid-point:

    // Get out your calculator!
    arc  0  5 (0.469846 0.17101  $zmin)
    arc  5 10 (0.17101  0.469846 $zmin)
    arc  1  4 (0.939693 0.34202  $zmin)
    arc  4  9 (0.34202  0.939693 $zmin)

Any discrepancy in the arc radius for the end points is resolved by adjusting the origin to ensure that the average radius is satisfied. For the rare cases where the arc angle is larger than 180 degrees, the traditional specification is still needed.

Source code

Improved PDRblockMesh

Mesh generation using the PDRblockMesh utility now includes expansion of the outer region. The expansion types are none, extend, box and sphere. e.g.

// Treatment of the outer region
    type        sphere;
    onGround    true;
    expansion   relative;

    ratios      1.1;

    size        3;
    nCells      10;
The box and sphere expansions use an O-grid topology as shown in the following figure:


Source code

Pre-processing: miscellaneous improvements

  • The transformPoints utility has been extended to include -recentre and -auto-origin options. These assist when applying mesh rotations around the mesh centre.
  • The surfaceTransformPoints utility now has distinct -read-scale and -write-scale options (as per the surfaceMeshConvert utility).
  • The surfaceRefineRedGreen now has a -steps option to perform successive refinement.