Now faceZones are handled directly by the applications and the new
faceZone::topoChange function so that any face can now be in any number of
zones, significantly increasing the flexibility and usefulness of faceZones.
This completes the generalisation of cellZone, faceZone and pointZone to support
multiple zones for each cell, face or point respectively. Next step will be to
make zones polymorphic and run-time selectable so that they can alter during the
run and adapt to moving meshes for example.
The concept of cell and face inflation proved unworkable in general and has been
replaced by the more flexible and robust cell-splitting combined with
conservative interpolative mapping and mesh morphing as appropriate.
gcc-13 has new code checking and warning mechanisms which are useful but not
entirely robust and produce many false positives, particularly with respect to
local references:
warning: possibly dangling reference to a temporary
This commit resolves many of the new warning messages but the above false
warnings remain. It is possible to switch off this warning but as it also
provides some useful checks it is currently left on.
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
This new mapping structure is designed to support run-time mesh-to-mesh mapping
to allow arbitrary changes to the mesh structure, for example during extreme
motion requiring significant topology change including region disconnection etc.
The polyTopoChangeMap is the map specifically relating to polyMesh topological
changes generated by polyTopoChange and used to update and map mesh related
types and fields following the topo-change.
This is a map data structure rather than a class or function which performs the
mapping operation so polyMeshDistributionMap is more logical and comprehensible
than mapDistributePolyMesh.
The code relating to extending refinement to the span of the facet/triangles
intersected by the refinement distance referred to in report
https://bugs.openfoam.org/view.php?id=3361
and temporarily removed may now be selected by the optional
castellatedMeshControls:extendedRefinementSpan entry in snappyHexMeshDict. It
in not clear if this control is generally beneficial and very few users have
reported a preference and too few example cases have been provided to make a
balanced judgement so it has been decided to reinstate the previous default
behaviour and default extendedRefinementSpan to true.
Within the snappyHexMeshDict castellatedMeshControls:
To select the cells outside a surface region:
outsidePoint <point>;
To select the cells outside a number of surface regions:
outsidePoints: (<point> <point>...);
To select the cells within a single surface region:
insidePoint <point>;
To select the cells within a number of surface regions:
insidePoints (<point> <point>...);
If the outside options are specified all cells are initially selected and those
within the surface regions selected by the points are deselected. Subsequently
the cells within the surface regions selected by the inside points are selected.
In order to select to keep the cells in multiple disconnected regions it is
necessary to specify a location in each of those regions as a list of points,
e.g.
castellatedMeshControls
{
.
.
.
locationsInMesh
(
(-0.18 0.003 0.05 )
(-0.09 0.003 0.05)
(0.09 0.003 0.05)
(0.18 0.003 0.05)
);
.
.
.
}
The locationInMesh control is still available for backward compatibility and to
specify a point when meshing a single region.
A single transformer object is now maintained within cyclic patches and returned
from a single virtual functions massively simplifying the interface and allowing
for further rationalisation of the calculation of the transformation.
Replaced all uses of complex Xfer class with C++11 "move" constructors and
assignment operators. Removed the now redundant Xfer class.
This substantial changes improves consistency between OpenFOAM and the C++11 STL
containers and algorithms, reduces memory allocation and copy overhead when
returning containers from functions and simplifies maintenance of the core
libraries significantly.
Registration occurs when the temporary field is transferred to a non-temporary
field via a constructor or if explicitly transferred to the database via the
regIOobject "store" methods.
Tree bound boxes are expanded asymmetrically to reduce the liklihood of
octree faces aliging with mesh faces and edges. The asymmetry is now
generated using hard-coded irrational numbers, rather than using a
random generator.
The asymmetry was effectively already hard coded. The random numbers are
only pseudo random, so the same numbers were being applied to the bound
boxes every time. This change simply removes the overhead of creating
the generator, and also gets rid of some duplicated code.
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
By default snappyHexMesh writes files relating to the hex-splitting process into
the polyMesh directory: cellLevel level0Edge pointLevel surfaceIndex
but by setting the noRefinement flag:
writeFlags
(
noRefinement
.
.
.
);
these optional files which are generally not needed are not written.
If you run the three stages of snappyHexMesh separately or run a dynamic mesh
solver supporting refinement and unrefinement these files are needed
and "noRefinement" should not be set.
The files relating to the hex refinement are written out explicitly both by
snappyHexMesh and dynamicRefineFvMesh and hence should be set "NO_WRITE" rather
than "AUTO_WRITE" to avoid writing them twice. This change corrects the
handling of the "refinementHistory" file which should not be written by
snappyHexMesh.
splitMeshRegions: handle flipping of faces for surface fields
subsetMesh: subset dimensionedFields
decomposePar: use run-time selection of decomposition constraints. Used to
keep cells on particular processors. See the decomposeParDict in
$FOAM_UTILITIES/parallel/decomposePar:
- preserveBaffles: keep baffle faces on same processor
- preserveFaceZones: keep faceZones owner and neighbour on same processor
- preservePatches: keep owner and neighbour on same processor. Note: not
suitable for cyclicAMI since these are not coupled on the patch level
- singleProcessorFaceSets: keep complete faceSet on a single processor
- refinementHistory: keep cells originating from a single cell on the
same processor.
decomposePar: clean up decomposition of refinement data from snappyHexMesh
reconstructPar: reconstruct refinement data (refineHexMesh, snappyHexMesh)
reconstructParMesh: reconstruct refinement data (refineHexMesh, snappyHexMesh)
redistributePar:
- corrected mapping surfaceFields
- adding processor patches in order consistent with decomposePar
argList: check that slaves are running same version as master
fvMeshSubset: move to dynamicMesh library
fvMeshDistribute:
- support for mapping dimensionedFields
- corrected mapping of surfaceFields
parallel routines: allow parallel running on single processor
Field: support for
- distributed mapping
- mapping with flipping
mapDistribute: support for flipping
AMIInterpolation: avoid constructing localPoints
