Optional CPU load caching can be switched-on for Lagrangian cloud tracking
and/or chemistry integration using the new cpuLoad switch in the cloudProperties
or chemistryProperties dictionary files respectively and used for
multi-constraint load-balancing by the fvMeshDistributorsLoadBalancer specified
in the dynamicMeshDict file
distributor
{
type loadBalancer;
libs ("libfvMeshDistributors.so");
multiConstraint true;
redistributionInterval 10;
}
which used the distributor specified in the decomposeParDict file, e.g.
numberOfSubdomains 12;
decomposer simple;
distributor zoltan;
libs ("libzoltanDecomp.so");
simpleCoeffs
{
n (2 2 3);
}
zoltanCoeffs
{
lb_method rcb;
}
The incompressibleDenseParticleFluid/cyclone case has been updated to
demonstrate this new functionality and shows a speedup ~50% using the Zoltan RCB
multi-constraint distributor. The multicomponentFluid/counterFlowFlame2D_GRI
case has also been updated to use the new cpuLoad switch.
The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
Both these boundary conditions now support specification of the radial
and tangential components as a function of time and radius, or
alternatively the tangential component as a time-varying rotational
speed.
The cylindricalInletVelocity condition has been superseeded by
swirlInletVelocity and has therefore been removed.
functionObjects layerAverage, nearWallFields, wallHeatFlux, wallHeatTransferCoeff,
wallShearStress and forcesBase now support both the 'patches' option for which a
list of regular expressions to select the patches is specified and the new simple
'patch' option for which a single patch name is specified.
Now the HashTable underlying PtrListDictionary is used for zone lookup by name
which is a lot faster than the linear search method used previously if there are
a large number of zones.
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.
//- Given a global object index, return the list of zones it is in
labelList whichZones(const label objectIndex) const;
which will replace the original whichZone function
//- Given a global object index, return the zone it is in.
// If object does not belong to any zones, return -1
// *** This will be replaced by whichZones
label whichZone(const label objectIndex) const;
so that cells, faces and points can exist in any number of zones.
The FV patches don't hold any data that requires updating. If they did,
then they would require a full set of mesh change hooks (i.e.,
topoChange, distribute, and mesh mapping, as well as move). The poly
patches currently hold all of this sort of data, and have a complete
system of methods to handle mesh changes.
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.
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.
This has required switching the order of dependence of the fvMesh
geometry (i.e., Sf, Cf, and C), and the interpolation weights. The
weights are now considered dependent on the geometry fields, and the
geometry fields must therefore construct without reference to the
weights.
This calculation more carefully constructs the direction of the area
stabilisation so as to ensure that it does not oppose the area being
stabilised. This prevents the creation of faces with zero area.
Resolves bug report https://bugs.openfoam.org/view.php?id=4040
These conditions are legacy and should not be considered for general
use. They require specific, unintuitive mesh structuring (i.e.,
duplicated boundary faces) that only PDRMesh can now create.
If an an interface is needed which opens or closes based on modelling
criteria, then this should be implemented as an extension of NCC. That
would be more flexible, parallelisable, and would not require
modification of the underlying polyheral mesh.
This returns the fraction of the poly-face that each fv-face in the
patch covers. This is useful for mapping some calculations from the
polyMesh to the fvMesh in cases with non-conformal couplings.
The nearWallDist MeshObject is now deleted on mesh-change rather than updated
which is more efficient for cases with multiple mesh changes, e.g. motion,
stitching and mapping by avoiding unnecessary updates.
As a consequence of this change the wallDist::y() volScalarField reference
should not be cached across mesh changes so the turbulence models now obtain the
y field as required from the new momentumTransportModel::y() function, the
original near-wall distance function is now named momentumTransportModel::yb()
to clarify that it is the wall distance of the boundary cells.
The nearWallDist MeshObject is now deleted on mesh-change rather than updated
which is more efficient for cases with multiple mesh changes, e.g. motion,
stitching and mapping by avoiding unnecessary updates.
It is simpler and more consistent to declare topological mesh objects as
moveable with a dummy movePoints function so that they remain unchanged if the
mesh moves without topology change. This allows the TopologicalMeshObject to be
removed altogether, the base MeshObjects type now being DeletableMeshObject
which are deleted on mesh change.
volPointInterpolation is now deleted on mesh-change rather than updated which is
more efficient for cases with multiple mesh changes, e.g. motion, stitching and
mapping by avoiding unnecessary updates.
These classes permit any PtrList of region-associated objects (meshes,
solvers, domainDecompositions, ...) to prefix the region name to the log.
At present these classes are used by decomposePar and reconstructPar
only. The foamMultiRun solver still handles its own prefixing.
