avoiding problems with mesh generation, pre/post-processing applications
etc. triggering inappropriate changes to the moving and topoChanged states which
are only needed for updates in solvers corresponding to mesh changes.
The topoChanged flag now indicates that the mesh topology has changed at the
start of the current time-step rather than it is changing during the run, for
subsequent time-steps without topology change it is set false until the next
topology change.
Mb, the Mach number at which blending to zeroGradient starts, can now be
specified in the input:
Description
This boundary condition provides an entrainment condition for pressure
including support for supersonic jets exiting the domain.
Usage
\table
Property | Description | Required | Default value
rho | Density field name | no | rho
psi | Compressibility field name | no | thermo:psi
gamma | Heat capacity ratio (cp/Cv) | yes |
Mb | Blending Mach No | no | 0.5
phi | Flux field name | no | phi
p0 | Reference pressure | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type transonicEntrainmentPressure;
gamma 1.4;
Mb 0.3;
p0 uniform 1e5;
}
\endverbatim
Specified in the dynamicMeshDict as type list with the topoChangers dictionary
list following, e.g.
topoChanger
{
type list;
libs ("libfvMeshTopoChangers.so");
topoChangers
{
refiner
{
type refiner;
.
.
.
}
another
{
type another;
.
.
.
}
}
}
These are introduced patches which do not correspond to any existing patches and
instead "cut" the internal mesh, thus requiring mapping from the internal mesh
fields rather than the patch fields. Cutting patches are specified using the
optional 'cuttingPatches' keyword, e.g. in dynamicMeshDict:
topoChanger
{
type meshToMesh;
libs ("libmeshToMeshTopoChanger.so");
cuttingPatches (splitter);
times (0.5 1.0);
timeDelta 1e-6;
}
This utility now always creates two patches, and only creates duplicate
faces when they connect to different cells and point in opposite
directions. Now that ACMI has been removed, there is no need to create
duplicate faces on the same cell and with similar orientations. This is
unituitive and is now considered an invalid mesh topology.
The preferred syntax for createBaffles is now as follows:
internalFacesOnly true;
baffles
{
cyclics
{
type faceZone;
zoneName cyclicFaces;
owner
{
name cyclicLeft;
type cyclic;
neighbourPatch cyclicRight;
}
neighbour
{
name cyclicRight;
type cyclic;
neighbourPatch cyclicLeft;
}
}
}
Note that the 'patches' sub-dictionary is not needed any more; the
'owner' and 'neighbour' sub-dictionaries can be in the same dictionary
as the parameters with which faces are selected. For backwards
compatibility, however, a 'patches' sub-dictionary is still permitted,
as are keywords 'master' and 'slave' (in place of 'owner' and
'neighbour', respectively).
The 'patchPairs' syntax has been removed. Whilst consise, this syntax
made a number of assumptions and decisions regarding naming conventions
that were not sufficiently intuitive for the user to understand without
extensive reference to the code. If identical boundaries are desired on
both sides of the patch, dictionary substitution provides a more
intuitive way of minimising the amount of specifiection required. For
example, to create two back-to-back walls, the following specification
could be used:
internalFacesOnly true;
fields true;
baffles
{
walls
{
type faceZone;
zoneName wallFaces;
owner
{
name baffleWallLeft;
type wall;
patchFields
{
p
{
type zeroGradient;
}
U
{
type noSlip;
}
}
}
neighbour
{
name baffleWallRight;
$owner; // <-- Use the same settings as for the owner
}
}
}
This boundary condition no longer stores its own mapping. It now has to
be applied to a mapped wall (or equivalent) patch, which does the
mapping for it. This ensures that mapping information is shared between
multiple fields, and that redundant copies are not generated.
For a single particle phase the divDevTau term in fvSchemes is now specified
thus:
divDevTau(U.particles) Gauss linear;
previously:
div((((thermo:rho.particles*nut.particles)*dev2(T(grad(U.particles))))+(((thermo:rho.particles*lambda.particles)*div(phi.particles))*I))) Gauss linear;
The sub mesh on which mesh fluxes are corrected potentially only exists
on a small subset of the processors. This was causing issues when
processor boundaries were evaluated as this triggered the construction
of weights and delta coefficients on only some of the processors,
causing a communications missmatch. This has been resolved by a
pre-emptive call to construct the surface interpolation coefficients.
to ensure complex BCs are selected and initialised correctly.
All mixture fields are now constructed and read as required in the construction
of the liquid (phase 1) mixtureKEpsilon model to ensure they are read before
time-increment and possible mesh topology change.
The 'pointSync' setting in createPatchDict is now optional and defaults
to false. This setting is very rarely used. A number of unused
'createPatchDict' files have also been removed and obsolete information
has been removed from the annotated example dictionaries.
The mesh will now be written only for the write time following mesh-motion or
topology change (refinement/unrefinement, mesh-to-mesh mapping, load-balancing
etc.) and not for all subsequent time-steps as it did previously. This reduces
storage and reconstruction effort of changing mesh cases.
When cloning a case, users can copy the field data from the
from the latest time directory in the source case, using
the -latestTime option.
The -startFrom option enables the copied time directory to be
renamed, often as the '0' (zero) directory in the new case, e.g.
foamCloneCase -latestTime -startFrom 0 sourceCase newCase
When the time directories in the source and new cases are
different, the uniform directory and flux field "phi" are
deleted from the copied time directory to avoid incorrect
initial state.
This utility can now add boundary conditions to fields which correspond
to the non-conformal patches that it adds to the mesh. This action is
enabled by means of a 'fields true;' flag which can be added to the
'system/createNonConformalCouplesDict'. No additional control is needed,
because all patches created by this utility are of constraint type.
