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.
The mergePatchPairs functionality in blockMesh also now uses patchIntersection.
The new mergePatchPairs and patchIntersection replaces the old, fragile and
practically unusable polyTopoChanger::slidingInterface functionality the removal
of which has allowed the deletion of a lot of other ancient and otherwise unused
clutter including polyTopoChanger, polyMeshModifier, polyTopoChange::setAction
and associated addObject/*, modifyObject/* and removeObject/*. This
rationalisation paves the way for the completion of the update of zone handling
allowing mesh points, faces and cells to exist in multiple zones which is
currently not supported with mesh topology change.
Application
stitchMesh
Description
Utility to stitch or conform pairs of patches,
converting the patch faces either into internal faces
or conformal faces or another patch.
Usage
\b stitchMesh (\<list of patch pairs\>)
E.g. to stitch patches \c top1 to \c top2 and \c bottom1 to \c bottom2
stitchMesh "((top1 top2) (bottom1 bottom2))"
Options:
- \par -overwrite \n
Replace the old mesh with the new one, rather than writing the new one
into a separate time directory
- \par -region \<name\>
Specify an alternative mesh region.
- \par -fields
Update vol and point fields
- \par -tol
Merge tolerance relative to local edge length (default 1e-4)
See also
Foam::mergePatchPairs
Omega lower limit bounding is now based on a maximum turbulence viscosity nut
rather than a minimum omega value which improves stability and robustness of
the k-omega models in case of numerical boundedness problems.
The maximum nut value is calculated by multiplying the laminar viscosity by
nutMaxCoeff which defaults to 1e5 but can be set by the user in the
momentumTransport dictionary.
Epsilon lower limit bounding is now based on a maximum turbulence viscosity nut
rather than a minimum epsilon value which improves stability and robustness of
the k-epsilon models in case of numerical boundedness problems.
The maximum nut value is calculated by multiplying the laminar viscosity by
nutMaxCoeff which defaults to 1e5 but can be set by the user in the
momentumTransport dictionary.
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.
An enumeration has been added to the arguments of the allocation
coefficient function, eta, to allow specification of how to allocate out
of bounds of the population balance size-groups. There are two options:
- "Clamp" will create an out-of-bounds allocation coefficient of exactly
one. This partitions unity across all size-space.
- "Extrapolate" will create an out-of-bounds allocation coefficient in
proportion to the ratio between the given size and the nearest
size-group size. This does not partition unity outside the range of
the size-groups.
The previous operation is equivalent to "Extrapolate".
It is not yet clear which method is preferable and under what
circumstances. More testing is required. The enumeration has been
created to facilitate this testing.
This prevents spurious factors of 1000 from being introduced in
thermodynamic models. It also generalises the system further with
respect to alternative unit sets.
The legacy fvMeshTopoChangersMovingCone removed, replaced by the more general
mesh mapping approach, see tutorials incompressibleFluid/movingCone and
shockFluid/movingCone.
The specie molecular mass (Wi) and formation enthalpy (hfi) methods now
return dimensioned scalars. This permits their direct inclusion into
dimensioned field expressions. Non-dimensioned methods have been
retained with a "Value" suffix (i.e., WiValue and hfiValue).
All property functions in the low-level templated thermo property
implementations and the high-level virtual interfaces have been made
consistent. All energies and enthalpies are lower case to denote that
they are specific quantities. Molar functions have been removed as these
are no longer used anywhere.
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.
This is consistent with the fluid solvers, and prevents failures
associated with using fields that haven't yet been updated or corrected
following mesh changes
This simple model creates a heat transfer coefficient in proportion with
the corresponding drag model's momentum transfer coefficient. A
user-defined Prandtl number and a harmonic average of the phases'
specific heats are used to specify the constant of proportionality.
This model has no physical basis. It exists primarily for testing
purposes. It has the advantage of being applicable to any interface,
including those representing segregated configurations.
Example usage:
heatTransfer
{
gas_segregatedWith_liquid
{
type Prandtl;
Pr 0.7;
}
}
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.
The directFieldMapper has been renamed to forwardFieldMapper, and
instances where generalFieldMapper was used instead of a more simple
forward/direct type have been removed.
The patch-specific mapper interfaces, fvPatchFieldMapper and
pointPatchFieldMapper, have been removed as they did not do anything.
Patch mapping constructors and functions now take a basic fieldMapper
reference.
An fvPatchFieldMapper.H header has been provided to aid backwards
compatability so that existing custom boundary conditions continue to
compile.
This lets calling code determine the difference between a polyMesh
topology change and a re-stitch. This prevents unnecessary
post-processing output in a few cases when using NCC; most notably the
generation of cellProc fields by reconstructPar.
Previously this was creating simple processorCyclic fields on the
nonConformalProcessorCyclic patches using a patchType override. The fact
that this worked is an encouraging indication of the system's
robustness, but it is more logical to create a field which directly
corresponds to the underlying patch type.
