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.
unless the blockMeshDict is in the polyMesh directory or the "-noClean" option
is specified.
This avoids problems running snappyHexMesh without first clearing files from
polyMesh which interfere with the operation of snappyHexMesh.
e.g. in tutorials/heatTransfer/buoyantSimpleFoam/externalCoupledCavity/0/T
hot
{
type externalCoupledTemperature;
commsDir "${FOAM_CASE}/comms";
file "data";
initByExternal yes;
log true;
value uniform 307.75; // 34.6 degC
}
Previously both 'file' and 'fileName' were used inconsistently in different
classes and given that there is no confusion or ambiguity introduced by using
the simpler 'file' rather than 'fileName' this change simplifies the use and
maintenance of OpenFOAM.
cellZones and pointZones can now be created in one action without the
need to first create a cellSet or pointSet and converting that to the
corresponding zone, e.g.
actions
(
// Example: create cellZone from a box region
{
name c0;
type cellZoneSet;
action new;
source boxToCell;
sourceInfo
{
box (0.04 0 0)(0.06 100 100);
}
}
);
For example, to mesh a sphere with a single block the geometry is defined in the
blockMeshDict as a searchableSurface:
geometry
{
sphere
{
type searchableSphere;
centre (0 0 0);
radius 1;
}
}
The vertices, block topology and curved edges are defined in the usual
way, for example
v 0.5773502;
mv -0.5773502;
a 0.7071067;
ma -0.7071067;
vertices
(
($mv $mv $mv)
( $v $mv $mv)
( $v $v $mv)
($mv $v $mv)
($mv $mv $v)
( $v $mv $v)
( $v $v $v)
($mv $v $v)
);
blocks
(
hex (0 1 2 3 4 5 6 7) (10 10 10) simpleGrading (1 1 1)
);
edges
(
arc 0 1 (0 $ma $ma)
arc 2 3 (0 $a $ma)
arc 6 7 (0 $a $a)
arc 4 5 (0 $ma $a)
arc 0 3 ($ma 0 $ma)
arc 1 2 ($a 0 $ma)
arc 5 6 ($a 0 $a)
arc 4 7 ($ma 0 $a)
arc 0 4 ($ma $ma 0)
arc 1 5 ($a $ma 0)
arc 2 6 ($a $a 0)
arc 3 7 ($ma $a 0)
);
which will produce a mesh in which the block edges conform to the sphere
but the faces of the block lie somewhere between the original cube and
the spherical surface which is a consequence of the edge-based
transfinite interpolation.
Now the projection of the block faces to the geometry specified above
can also be specified:
faces
(
project (0 4 7 3) sphere
project (2 6 5 1) sphere
project (1 5 4 0) sphere
project (3 7 6 2) sphere
project (0 3 2 1) sphere
project (4 5 6 7) sphere
);
which produces a mesh that actually conforms to the sphere.
See OpenFOAM-dev/tutorials/mesh/blockMesh/sphere
This functionality is experimental and will undergo further development
and generalization in the future to support more complex surfaces,
feature edge specification and extraction etc. Please get involved if
you would like to see blockMesh become a more flexible block-structured
mesher.
Henry G. Weller, CFD Direct.
blockMesh -help
Usage: blockMesh [OPTIONS]
options:
-blockTopology write block edges and centres as .obj files
-case <dir> specify alternate case directory, default is the cwd
-dict <file> specify alternative dictionary for the blockMesh description
-noFunctionObjects
do not execute functionObjects
-region <name> specify alternative mesh region
-srcDoc display source code in browser
-doc display application documentation in browser
-help print the usage
Block description
For a given block, the correspondence between the ordering of
vertex labels and face labels is shown below.
For vertex numbering in the sequence 0 to 7 (block, centre):
faces 0 (f0) and 1 are left and right, respectively;
faces 2 and 3 are bottom and top;
and faces 4 and 5 are front the back:
4 ---- 5
f3 |\ |\ f5
| | 7 ---- 6 \
| 0 |--- 1 | \
| \| \| f4
f2 3 ---- 2
f0 ----- f1
Using: OpenFOAM-dev (see www.OpenFOAM.org)
Build: dev-dc59c63351e7
- the checking for point-connected multiple-regions now also writes the
conflicting points to a pointSet
- with the -writeSets option it now also reconstructs & writes pointSets
In parallel the sets are reconstructed. e.g.
mpirun -np 6 checkMesh -parallel -allGeometry -allTopology -writeSets vtk
will create a postProcessing/ folder with the vtk files of the
(reconstructed) faceSets and cellSets.
Also improved analysis of disconnected regions now also checks for point
connectivity with is useful for detecting if AMI regions have duplicate
points.
Patch contributed by Mattijs Janssens
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
to have the prefix 'write' rather than 'output'
So outputTime() -> writeTime()
but 'outputTime()' is still supported for backward-compatibility.
Also removed the redundant secondary-writing functionality from Time
which has been superseded by the 'writeRegisteredObject' functionObject.
These new names are more consistent and logical because:
primitiveField():
primitiveFieldRef():
Provides low-level access to the Field<Type> (primitive field)
without dimension or mesh-consistency checking. This should only be
used in the low-level functions where dimensional consistency is
ensured by careful programming and computational efficiency is
paramount.
internalField():
internalFieldRef():
Provides access to the DimensionedField<Type, GeoMesh> of values on
the internal mesh-type for which the GeometricField is defined and
supports dimension and checking and mesh-consistency checking.
Non-const access to the internal field now obtained from a specifically
named access function consistent with the new names for non-canst access
to the boundary field boundaryFieldRef() and dimensioned internal field
dimensionedInternalFieldRef().
See also commit 22f4ad32b1
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now. Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit 4a57b9be2e
This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so
volScalarField::DimensionedInternalField -> volScalarField::Internal
In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions. To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.