The 'featureAngle' control defines the included angle between faces
above which layer extrusion is prevented. Its use within snappyHexMesh
was incorrect in that the cosine was not being taken before being
compared to dot products of face normals. This has now been corrected.
Existing 'featureAngle' settings may need changing to recover equivalent
behaviour. Any angle previously set to 58 degrees or above previously
resulted in no reduction of layer coverage. A large angle between 90 and
180 degrees is likely to be an appropriate replacement for cases such as
this. Angles previously set to 57 degrees and below can be equivalently
replaced by a value of (180/pi)*arccos(<angle>*(pi/180)).
Note that changing the feature angle also affects the slip feature
angle. The slip feature angle is taken to be half the feature angle if a
'slipFeatureAngle' is not specified.
The defaultPatch type currently defaults to empty which is appropriate for 1D
and 2D cases but not when creating the initial blockMesh for snappyHexMesh as
the presence of empty patches triggers the inappropriate application of 2D point
constraint corrections following snapping and morphing. To avoid this hidden
problem a warning is now generated from blockMesh when the defaultPatch is not
explicitly set for cases which generate a default patch, i.e. for which the
boundary is not entirely defined. e.g.
.
.
.
Creating block mesh topology
--> FOAM FATAL IO ERROR:
The 'defaultPatch' type must be specified for the 'defaultFaces' patch, e.g. for snappyHexMesh
defaultPatch
{
name default; // optional
type patch;
}
or for 2D meshes
defaultPatch
{
name frontAndBack; // optional
type empty;
}
.
.
.
All the tutorials have been update to include the defaultPatch specification as
appropriate.
When snappyHexMesh is run in parallel it re-balances the mesh during refinement
and layer addition by redistribution which requires a decomposition method
that operates in parallel, e.g. hierachical or ptscotch. decomposePar uses a
decomposition method which operates in serial e.g. hierachical but NOT
ptscotch. In order to run decomposePar followed by snappyHexMesh in parallel it
has been necessary to change the method specified in decomposeParDict but now
this is avoided by separately specifying the decomposition and distribution
methods, e.g. in the incompressible/simpleFoam/motorBike case:
numberOfSubdomains 6;
decomposer hierarchical;
distributor ptscotch;
hierarchicalCoeffs
{
n (3 2 1);
order xyz;
}
The distributor entry is also used for run-time mesh redistribution, e.g. in the
multiphase/interFoam/RAS/floatingObject case re-distribution for load-balancing
is enabled in constant/dynamicMeshDict:
distributor
{
type distributor;
libs ("libfvMeshDistributors.so");
redistributionInterval 10;
}
which uses the distributor specified in system/decomposeParDict:
distributor hierarchical;
This rationalisation provides the structure for development of mesh
redistribution and load-balancing.
for consistency with the regionToCell topo set source and splitMeshRegions and
provides more logical extension to the multiple and outside point variants insidePoints,
outsidePoint and outsidePoints.
When using 'simple' or 'hierarchical' decomposition it is useful to slightly rotate a
coordinate-aligned block-mesh to improve the processor boundaries by avoiding
irregular cell distribution at those boundaries. The degree of slight rotation
is controlled by the 'delta' coefficient and a value of 0.001 is generally
suitable so to avoid unnecessary clutter in 'decomposeParDict' 'delta' now
defaults to this value.
The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
The inside or outside region refinement level is now specified using the simple
"level <level>" entry in refinementRegions e.g.
refinementRegions
{
refinementBox
{
mode inside;
level 5;
}
}
rather than
refinementRegions
{
refinementBox
{
mode inside;
levels ((1E15 5));
}
}
where the spurious "1E15" number is not used and the '((...))' is unnecessary clutter.
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
The closeness option in surfaceFeatures set in surfaceFeaturesDict, e.g.
closeness
{
// Output the closeness of surface points to other surface elements.
pointCloseness yes;
}
calculates and writes both the internal and external surface "closeness"
measures either of which could be used to set the span refinement in
snappyHexMesh depending on which side of the surface is being meshed which is
specified with either refinement mode "insideSpan" or "externalSpan", e.g. in
the tutorials/mesh/snappyHexMesh/pipe case the inside of the pipe is meshed and
refined based on the internal span using the following specification:
refinementRegions
{
pipeWall
{
mode insideSpan;
levels ((1000 2));
cellsAcrossSpan 40;
}
}
To handle the additional optional specification for the closeness calculation
these settings are now is a sub-dictionary of surfaceFeaturesDict, e.g.
closeness
{
// Output the closeness of surface elements to other surface elements.
faceCloseness no;
// Output the closeness of surface points to other surface elements.
pointCloseness yes;
// Optional maximum angle between opposite points considered close
internalAngleTolerance 80;
externalAngleTolerance 80;
}
In the new tutorial mesh/snappyHexMesh/pipe the pipe diameter changes by a factor
of 2 but the number of cells across the pipe is specified to be constant along
the length using the new "span" refinement mode in which the number of cells
across the span is set to be at least 40:
refinementRegions
{
pipe
{
mode span;
levels ((1000 2)); // Maximum distance and maximum level
cellsAcrossSpan 40;
}
}
This operates in conjunction with the "pointCloseness" option in surfaceFeatures
which writes a surfacePointScalarField of the local span of the domain. Note
that the behaviour of this option is critically dependent on the quality of this
field and the surface may need to be re-triangulated more isotropically to
ensure the "pointCloseness" is accurate and representative of the domain and the
required mesh distribution.
RunFunctions: Added "isTest()" argument parsing function
tutorials: Updated Allrun scripts to propagate the "-test" option
tutorials: Removed the lower Alltest scripts and updated the Allrun to
use the "isTest()" function to handle test-specific operation
Description
Specify an etc file to include when reading dictionaries, expects a
single string to follow.
Searches for files from user/group/shipped directories.
The search scheme allows for version-specific and
version-independent files using the following hierarchy:
- \b user settings:
- ~/.OpenFOAM/\<VERSION\>
- ~/.OpenFOAM/
- \b group (site) settings (when $WM_PROJECT_SITE is set):
- $WM_PROJECT_SITE/\<VERSION\>
- $WM_PROJECT_SITE
- \b group (site) settings (when $WM_PROJECT_SITE is not set):
- $WM_PROJECT_INST_DIR/site/\<VERSION\>
- $WM_PROJECT_INST_DIR/site/
- \b other (shipped) settings:
- $WM_PROJECT_DIR/etc/
An example of the \c \#includeEtc directive:
\verbatim
#includeEtc "etcFile"
\endverbatim
The usual expansion of environment variables and other constructs is
retained.
For multi-region cases the default location of blockMeshDict is now system/<region name>
If the blockMeshDict is not found in system then the constant directory
is also checked providing backward-compatibility
