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.
For a case extruding patches left and right:
sourcePatches (left right);
if the optional zoneNames entry is also specified in extrudeMeshDict
zoneNames (leftCells rightCells);
the cells extruded from the left patch are added to the leftCells cellZone and
the cells extruded from the right patch are added to the rightCells cellZone.
Alternatively if a single zone name is specified, e.g.
zoneNames (extrudedCells);
then cells extruded from the left and right patches are added to the
extrudedCells cellZone.
If the number of patches to extrude is large it might be more convenient for
the cells extruded from each patch to be added to a cellZone named the same as
each patch, this option is selected by setting zoneNames to patchNames:
zoneNames (patchNames);
Now cellZones are handled directly by the applications and the new
cellZone::topoChange function so that any cell can now be in any number of
zones, significantly increasing the flexibility and usefulness of cellZones.
The same rationalisation and generalisation will be applied to faceZones in the
future.
Now pointZones are handled directly by the applications and the new
pointZone::topoChange function so that any point can now be in any number of
zones, significantly increasing the flexibility and usefulness of pointZones.
The same rationalisation and generalisation will be applied to cellZones and
faceZones in the future.
The surface mesh setPoints function resets the points without caching the old
points or swept areas so is the equivalent of the polyMesh::setPoints rather
than movePoints.
This utility is superseded by the much more general transformPoints. A
rotation between vectors (0 1 0) and (0.707107 0.707107 0), and a
corresponding transformation of all vector and tensor fields, can be
achieved with the following call to transformPoints:
transformPoints "rotate=((0 1 0) (0.707107 0.707107 0))" -rotateFields
This boundary condition provides a cyclic condition for p_rgh. It applies
corrections to the value and gradient on both sides of the cyclic to
account for the non-cylicity of the gravitational force.
This condition is only needed when the cyclic patches have a transformation
and a normal component in the direction of gravity. If the cyclic patches
are orthogonal to the direction gravity, then a normal cyclic boundary
condition can be used instead.
Care must be taken when using this boundary condition that the simulation
is actually cyclic. The following constraints apply:
- Both cyclic patches must be oriented in the same way with respect to
gravity. In practice this means that applicability is limited to cyclics
with translational transformations.
- The model cannot have any dependence on the absolute value of the
pressure field. The absolute value of the pressure, in reality, varies
between each repetition of the geometry; it is not actually formally
cyclic. Only the gradient of the pressure field can be truly cyclic. This
model is therefore only valid if the absolute value of the pressure is
arbitrary, and only the gradient has an effect on the solution. This is
the case for incompressible multiphase solutions or incompressible
Boussinesq-like models of density variation. It is not true if (for
example) a compressible thermodynamic model is being used.
Specification is as follows. A "patchType" entry must be provided to
indicate that this condition overrides the underlying cyclic constraint,
and a "rhoInf" entry is needed (by the owner patch only) to specify the
density of the far-field environment. For example:
cyclicA
{
type prghCyclicPressure;
patchType cyclic;
rhoInf 1; // [kg/m^3]
}
cyclicB
{
type prghCyclicPressure;
patchType cyclic;
}
A tutorial, incompressibleVoF/trayedPipe, has been added to demonstrate
usage of this boundary condition.
The base jump cyclic patch now no longer assumes that the jump applies
equally to both sides. The jump() method for a field now returns the
jump appropriate for a transfer to the field in question; the base patch
no longer has to do any explicit negation. This provides the opportunity
to create alternative types of jump.
The derived classes are now well defined in terms of their construction.
No conditions require a "value" entry. Whether or not a "jump" entry
is required depends on whether the condition can re-calculate the jump
field without reference to other fields or boundary conditions. The
presence or otherwise of a jump or value entry should no longer result in
lookup failures or floating point errors or similar.
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.
The concept of cell inflation from faces or points 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.
The syntax of this model has changed to permit transfers of species in
either direction. A list of transferring species is now given for each
phase, rather than identifying a single reacting phase. For example:
phaseTransfer
(
vapour_particles
{
type reactionDriven;
// TiO2 and TiO2_s are created by reactions in the vapour
// and are then transferred to the particles
species.vapour (TiO2 TiO2_s);
// H2O is created by reactions in the particles and is then
// transferred to the vapour
species.particles (H2O);
}
);
