# OpenFOAM® v2012: New and improved numerics

23/12/2020

## New run-time geometry calculation selection

This release adds user-selectable geometry calculation. The system/fvSchemes dictionary now has an optional geometry section which overrides the method to calculate the geometric properties:

geometry
{
// Use specialised method for high-aspect ratio cells
type        highAspectRatio;
minAspect   10;     // when to start blending lower-order method
maxAspect   100;    // when to use lower-order method only
}
The selected fvGeometryScheme is responsible for calculating
• faceCentres, faceAreas
• cellCentres, cellVolumes
• linear interpolation weights
• cell-centre distance
• non-orthogonality corrections

The following schemes are available:

basic
This is the default scheme and provides the exact behaviour as previous versions. It calculates the mass centroid for faces and cells.
stabilised
Face centres are calculated using only positive triangle contributions and is supposedly more stable on concave/distorted faces. This is the default in openfoam.org.
highAspectRatio
This scheme blends between basic and an edge-length weighted, face-area weighted average. This avoids truncation errors on high aspect ratio cells, at the cost of being lower order. The blending is linear across the range minAspect, maxAspect (see example above).
averageNeighbour
Similar to highAspectRatio but followed by a pass to align cell centres on top of one another to minimise non-orthogonality.

Specifying the method to calculate the geometric properties instead of e.g. limiting the effect on discretisation means that it also affects the mesh generation. This is especially important for mesh generators that use the mesh quality e.g.snappyHexMesh.

##### High-aspect ratio meshes

The averageNeighbour scheme can be very effective for tetrahedral and high-aspect ratio prismatic boundary layer meshes. These might have a very high non-orthogonality angle in the prism boundary layer due to truncation errors and alignment.

The figure below shows a comparison of the distribution of the non-orthogonality angle when computed with the basic scheme (left) and averageNeighbour (right).

Note:

• all solvers and applications using fvMesh or its derivatives, e.g.dynamicFvMesh, should work with the user-selectable geometry schemes. Any application using the underlying polyMesh level, e.g.blockMesh, will not and use the basic functionality.
• any user-coded dynamicMesh might have to be adapted to be able to use the new schemes. If not it will use the basic functionality.
• the highAspectRatio and averageNeighbour schemes are still under active investigation and development.
• checkMesh -writeAllFields provides an easy way to visualise the non-orthogonality and estimated aspect ratio using the current scheme.

Source code
$FOAM_SRC/finiteVolume/fvMesh/fvGeometryScheme Tutorial$FOAM_TUTORIALS/mesh/snappyHexMesh/airfoilWithLayers

## Lagrangian: Improved particle tracking on moving meshes

This release includes several improvements to particle tracking on moving mesh cases. These cases would often fail in earlier versions due to:

1. particles crossing AMI patches;
2. particle-wall interactions; and
3. fragility of the barycentric tracking (ported from openfoam.org)

##### Improved particle-cyclicAMI patch interaction

When a particle hits a cyclicAMI patch it is transported to its neighbour cyclicAMI patch. This could lead to a situation where the particle continually ’bounces’ between both sides. The behaviour can be avoided using new fraction keyword, specified in the cyclicAMI patch entry of the constant/polyMesh/boundary file, which advances the particle inside the receiving cell by a specified fraction. Note that the particle is tracked from fraction zero to one.

By defauly, the fraction is set to zero for backwards compatibility. If non-zero the fraction is added to the tracking fraction when hitting the face.

Tutorial

##### More robust tracking

The barycentric tracking was made more robust to address issues when the cell barycentric coordinate decomposition becomes negative. This improvement was ported from openFoam.org.

##### Modifications on MPPIC cloud

The MPPIC sub-models have been transferred from the MPPIC to the kinematic cloud. The MPPIC sub-models, i.e. packing, damping, etc. provide a velocity correction to the particles near the packing zone. To avoid additional tracking of these particles the correction is now applied in the kinematic cloud.

This improves performance in highly packed beds where the velocity correction can be considerable.

This change is transparent to the user and the MPPIC solvers (MPPICDyMFoam and MPPICFoam) are still available.

Source code
$FOAM_SRC/lagrangian/intermediate/clouds/Templates/KinematicCloud Tutorial$FOAM_TUTORIALS/lagrangian/MPPICDyMFoam/column/