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 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:
- overallAndExpansion; or
The selection determines which of the thickness controls need to be present:
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
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:
// 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);
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);
- 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:
// Default is 0 (= disabled)
Once enabled, additional output is generated of the form:
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:
extrudeMesh: new polyLine option
The new polyline extrusion model employs the functionality of blockMesh edges to define the extrusion path.
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:
( 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 )
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
- Source code
- Contribution by Ivor Clifford (Paul Scherrer Institut)
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
Mesh generation using the PDRblockMesh utility now includes expansion of the outer region. The expansion types are none, extend, box and sphere. e.g.
- 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.