Either single entries renamed using the -entry option with -rename:
-entry <entryName> -rename <newName>
or a list of entries can be renamed using the -rename <newNames> option:
-rename "<entryName0>=<newName0>, <entryName1>=<newName1>..."
These models represent a phase nucleating directly out of a
multi-component mixture into isolated particles (i.e., homogeneous),
rather than onto an existing surface or impurity (heterogeneous).
The homogeneousCondensation model can represent the initial stages of a
gas condensing into a liquid. Example usage, in constant/fvModels:
homogeneousCondensation
{
type homogeneousCondensation;
libs ("libmultiphaseEulerFvModels.so");
// Phases between which the transfer occurs. The first phase is the
// gas, and the second is the condensed liquid.
phases (gas water);
// The specie that is condensing
specie H2O;
// Linearise the latent heat contribution into the energy equation?
energySemiImplicit no;
// Saturation curve for the specie in the gaseous phase
pSat ArdenBuck;
}
The homogeneousLiquidPhaseSeparation model can represent the initial
stages of a liquid solution precipitating out a solid or separating into
two immiscible liquid phases: Example usage, in constant/fvModels:
homogeneousLiquidPhaseSeparation
{
type homogeneousLiquidPhaseSeparation;
libs ("libmultiphaseEulerFvModels.so");
// Phases between which the transfer occurs. The first phase is the
// solution, and the second is the precipitate.
phases (liquid sugar);
// The specie that is condensing
specie C2H12O6;
// Linearise the latent heat contribution into the energy equation?
energySemiImplicit no;
// Solubility given in mass of solute per mass of solvent
solubility constant 0.9;
}
If population balance is being used, then both of these models require a
source term to be applied to the size-group equations. This is achieved
by means of a new nucleationSizeGroup field source. Example usage, in
0/fDefault.water:
sources
{
homogeneousCondensation
{
type nucleationSizeGroup;
libs ("libmultiphaseEulerFvModels.so");
}
}
Functions have been added to populationBalance to generate the
volumetric allocation coefficient etaV. This is needed if a volume or
mass source is to be conveniently distributed into the size groups. The
number-based allocation coefficient, eta, is still available and is
still used in all cases within populationBalance.
The allocation bounds handling has been removed. This, as it turns out,
was just an incomplete subset of having both number- and volume-based
allocation coefficients implemented.
This thermal wall function now asks the corresponding nut wall function
for yPlus, rather than calculating it itself from the turbulent kinetic
energy. This simplifies the implementation and should improve
consistency between the near-wall modelling of the heat and momentum
transfers.
The heat-flux dependent terms in this boundary condition have also been
removed. The origin of these terms is unclear, and their value increases
without limit as the thermal boundary condition tends towards the case
of an adiabatic wall. These terms, or something eqivalent, could be
reinstated in a separate boundary condition if a clear reference was
provided and a case found for which tangible benefit could be
demonstrated.
Zones are now completely dynamic, i.e. the number of zones of each type can
change during the run, e.g. by run-time mesh-to-mesh mapping onto meshes with
different zones used to control mesh motion. This means that the index of each
zone may change during the run and so it better that the zones do not cache
their own index but it is looked-up from the zone list using findIndex when
required.
A new nonConformalMappedWall patch type has been added which can couple
between different regions of a multi-region simulation. This patch type
uses the same intersection algorithm as the nonConformalCyclic patch,
which is used for coupling sections of a mesh within the same region.
The nonConformalMappedWall provides some advantages over the existing
mappedWall patches:
- The connection it creates is not interpolative. It creates a pair of
coupled finite-volume faces wherever two opposing faces overlap.
There is therefore no interpolation error associated with mapping
values across the coupling.
- Faces (or parts of faces) which do not overlap are not normalised
away by an interpolation or averaging process. Instead, they are
assigned an alternative boundary condition; e.g., an external
constraint, or even another non-conformal cyclic or mapped wall.
This makes the system able to construct partially-overlapping
couplings.
- The direct non-interpolative transfer of values between the patches
makes the method equivalent to a conformal coupling. Properties of
the solution algorithm, such as conservation and boundedness, are
retained regardless of the non-conformance of the boundary meshes.
- All constructed finite volume faces have accurate centre points.
This makes the method second order accurate in space.
Usage:
Non-conformal mapped wall couplings are constructed as the last stage of
a multi-region meshing process. First, a multi-region mesh is
constructed in one of the usual ways, but with the boundaries specified
as standard non-coupled walls instead of a special mapped type. Then,
createNonConformalCouples is called to construct non-conformal mapped
patches that couple overlapping parts of these non-coupled walls. This
process is very similar to the construction of non-conformal cyclics.
createNonConformalCouples requires a
system/createNonConformalCouplesDict in order to construct non-conformal
mapped walls. Each coupling is specified in its own sub-dictionary, and
a "regions" entry is used to specify the pair of regions that the
non-conformal mapped wall will couple. Non-conformal cyclics can also be
created using the same dictionary, and will be assumed if the two
specified regions are the same, or if a single "region" entry is
specified. For example:
// Do not modify the fields
fields no;
// List of non-conformal couplings
nonConformalCouples
{
// Non-conformal cyclic interface. Only one region is specified.
fluidFluid
{
region fluid;
originalPatches (nonCoupleRotating nonCoupleStationary);
}
// Non-conformal mapped wall interface. Two different regions
// have been specified.
fluidSolid
{
regions (fluid solid);
originalPatches (nonCoupleRotating nonCoupleStationary);
}
}
After this step, a case should execute with foamMultiRun and decompose
and reconstruct and post-process normally.
One additional restriction for parallelised workflows is that
decomposition and reconstruction must be done with the -allRegions
option, so that the both sides of the coupling are available to the
decomposition/reconstruction algorithm.
Tutorials:
Two tutorials have been added to demonstrate use of this new
functionality:
- The multiRegion/CHT/misalignedDuct case provides a simple visual
confirmation that the patches are working (the exposed corners of
the solid will be hot if the non-conformal mapped walls are active),
and it demonstrates createNonConformalCouples's ability to add
boundary conditions to existing fields.
- The multiRegion/CHT/notchedRoller case demonstrates use of
non-conformal mapped walls with a moving mesh, and also provides an
example of parallelised usage.
Notes for Developers:
A coupled boundary condition now uses a new class,
mappedFvPatchBaseBase, in order to perform a transfer of values to or
from the neighbouring patch. For example:
// Cast the patch type to it's underlying mapping engine
const mappedFvPatchBaseBase& mapper =
mappedFvPatchBaseBase::getMap(patch());
// Lookup a field on the neighbouring patch
const fvPatchScalarField& nbrTn =
mapper.nbrFvPatch().lookupPatchField<volScalarField, scalar>("T");
// Map the values to this patch
const scalarField Tn(mapper.fromNeighbour(nbrTn));
For this to work, the fvPatch should be of an appropriate mapped type
which derives from mappedFvPatchBaseBase. This mappedFvPatchBaseBase
class provides an interface to to both conformal/interpolative and
non-conformal mapping procedures. This means that a coupled boundary
condition implemented in the manner above will work with either
conformal/interpolative or non-conformal mapped patch types.
Previously, coupled boundary conditions would access a mappedPatchBase
base class of the associated polyPatch, and use that to transfer values
between the patches. This direct dependence on the polyPatch's mapping
engine meant that only conformal/interpolative fvPatch fields that
corresponded to the polyPatch's geometry could be mapped.
This boundary condition provides a no-slip velocity condition for mapped
walls. The wall velocity is taken to be the mesh velocity of the
neighbouring region.
This will typically be used in CHT simulations in order to apply the
mesh motion of a solid region to the boundary of the adjacent fluid
region.
Example of the boundary condition specification:
<patchName>
{
type movingMappedWallVelocity;
value uniform (0 0 0); // Initial value
}
This provides finer control as to when the changes get constructed and
initial stitching is performed. These is needed by certain processes,
notably decomposition and reconstruction.
By default, the mesh still performs all these operations on a "normal"
read-construction. A flag has to be passed explicitly to the constructor
in order to prevent the post-construction steps.
A number of boundary conditions' mapping constructors and methods have
been modified so as to specify what value gets applied to a new or
unmapped face. This allows them to be maintained throughout mesh changes
in which faces are created without reference to a parent or master face.
For example, the coupled temperature condition now creates values
representative of an adiabatic wall on new faces. If the faces didn't
exist prior to mapping, then there was previously no heat flux at these
locations, so an adiabatic constraint is a sensible initialisation.
Mapping functions can now, where appropriate, tell a field mapper to
assign specific values for un-mapped elements of the field. This is
achieved by means of new operators which take an additional argument of
either a value or a field-generating function. This value or function is
used to initialise the unmapped elements.
Now that BasicThermo::Cp returns a volScalarField reference because Cp is cached
in BasicThermo code calling Cp can hold a reference rather than a copy for
efficiency.
rather than from the energy gradient, consistent with the current form of energy
equations in OpenFOAM solvers in which diffusive thermal transport is
temperature gradient based with a semi-implicit energy gradient correction term.
to set the time and other case controls. This is possible and reliable now that
the functionObject specifications are in a separate functions file which is not
read.
for consistency with fvModels and fvConstraints, to simplify code and case
maintenance and to avoid the potentially complex functions entries being
unnecessarily parsed by utilities for which functionObject evaluation is
disabled.
The functions entry in controlDict is still read if the functions file is not
present for backward-compatibility, but it is advisable to migrate cases to use
the new functions file.
Description
Merges meshes without stitching.
Usage
\b mergeMeshes [OPTION]
Options:
- \par -doc
Display the documentation in browser
- \par -srcDoc
Display the source documentation in browser
- \par -help
Print the usage
- \par -case \<dir\>
Select a case directory instead of the current working directory
- \par -region \<name\>
Specify an alternative mesh region.
- \par -addRegions "'(region1 region2 ... regionN)'"
Specify list of region meshes to merge.
- \par -addCases "'(\"casePath1\" \"casePath2\" ... \"casePathN\")'"
Specify list of case meshes to merge.
- \par -addCaseRegions "'((\"casePath1\" region1) (\"casePath2\" region2)"
Specify list of case region meshes to merge.
The Clang compiler does not use std::move to transfer the result of the ternary
operator into the phase-fraction field resulting in it not being registered to
the database. To work around this limitation/bug the ternary operator is now
provided with tmp fields the result of which is passed with an IOobject to the
final field constructor to ensure it is registered and the IO options set
correctly.
Coded functionality now supports basic un-typed substitutions from the
surrounding dictionary. For example:
value 1.2345;
#codeExecute
{
scalar s = $value;
...
};
It also now supports the more functional typed substitutions, such as:
direction (1 0 0);
#codeExecute
{
vector v = $<vector>direction;
...
};
These substitutions are now possible in all code blocks. Blocks with
access to the dictionary (e.g., #codeRead) will do a lookup which will
not require re-compilation if the value is changed. Blocks without
access to the dictionary will have the value directly substituted, and
will require recompilation when the value is changed.
These wall functions modify the turbulent properties (epsilon or omega,
and G) in the adjacent cells. When a cell has multiple wall faces, a
weighting process is used to combine the values from the different
walls. This weighting process has been rewritten and centralised into a
common base class. It is now based on an area-weighted average and is
applied to the fields in an order-independent manner. It is now fully
consistent with multiple simultaneous non-conformal connections.
//- Find and return the zone indices for all matches
labelList findIndices(const wordRe&) const;
It may also be useful to provide versions taking a list of word or wordRe which
will be added as required.
such that the point-edge wave can be stopped when the distance from the
originating surface exceeds the specified maximum if distances beyond this are
of no interest as is the case for rigid-body motion with a specified outer
distance. Stopping the point-edge in this manner can significantly speed-up the
calculation, particularly in parallel as the number of expensive communications
is reduced.
