Latent heat evaluation has been changed to calculate both sides' heats
similarly using the interface temperature, rather than using bulk
quantities on the "upwind" side of the mass transfer process
(latentHeatScheme::symmetric vs latentHeatScheme::upwind).
The transfer of heat has been changed so that it is calculated from the
mass transfer rate rather than the heat transfer coefficients and
temperatures (latentHeatTransfer::mass vs latentHeatTransfer::heat).
These changes were found to improve stability characteristics in some
boiling cases, and in general should be more energy conservative and
less dependent on the accuracy of the interfacial temeprature solution.
Patch contributed by Juho Peltola, VTT.
The new option takes a value indicating which cell types should be
written out as polyhedra. The values are as follows:
none: No polyhedral cells are written. Cells which match specific
shapes (hex, pyramid, prism, ...) are written as their
corresponding VTK cell types. Arbitrary polyhedral cells
that do not match a specific shape are decomposed into
tetrahedra.
polyhedra: Only arbitrary polyhedral cells are written as a VTK
polyhedron. Cells that match specific shapes are written as
their corresponding VTK cell types.
all: All cells are written as a VTK polyhedron.
The default is 'none', which retains the previous default behaviour.
Two pitzDaily variants have been added; pitzDailySteadyMappedToPart, and
pitzDailySteadyMappedToRefined. These demonstrate usage of workflows
which involve mapping between cases with mapFieldsPar.
The pitzDailySteadyMappedToPart case demonstrates mapping onto a small
section of the mesh; in this case in the vicinity of the the corner of
the backstep. This mesh is not consistent with the source data, so
fields are required in the zero directory and cutting patches are used
to specify the properties at the inlets.
The pitzDailySteadyMappedToRefined case demonstrates mapping onto a
geometrically similar case with a different mesh density. This mesh is
consistent with the source, so no fields are needed and no cutting
patches are used. This case does, however, perturb the geometry of the
block mesh a bit, so that some of the refined case is not overlapping
the original case. This provides a test of the stabilisation
procedures within the mesh-to-mesh mapping functions.
Stabilisation has been added to the mapping of fields between consistent
meshes. This means that if part of the target mesh is found not to
connect with the source mesh, then its values will be set by propagating
a value from the closest part of the target mesh did successfully
connect to the source. This propagation is achieved by means of a mesh
wave.
This stabilisation applies to both cell and patch fields, and any and
all ancillary fields that may be being stored by the patch boundary
conditions. It applies to the mapping performed by both mapFieldsPar and
the run-time mapping meshToMesh topology changer.
This fixes the previous situation in mapping between consistent meshes
in which target elements which did not connect to the source would be
given an undefined value, which would cause either a floating point
error, or (worse) incorrect operation.
Cell-to-cell interpolation has been moved to a hierarchy separate from
meshToMesh, called cellsToCells. The meshToMesh class is now a
combination of a cellsToCells object and multiple patchToPatch objects.
This means that when only cell-to-cell interpolation is needed a basic
cellsToCells object can be selected.
Cell-to-cell and vol-field-to-vol-field interpolation now has two well
defined sets of functions, with a clear distinction in how weights that
do not sum to unity are handled. Non-unity weights are either
normalised, or a left-over field is provided with which to complete the
weighted sum.
The left-over approach is now consistently applied in mapFieldsPar,
across both the internal and patch fields, if mapping onto an existing
field in the target case. Warning are now generated for invalid
combinations of settings, such as mapping between inconsistent meshes
without a pre-existing target field.
All mapping functions now take fields as const references and return tmp
fields. This avoids the pattern in which non-const fields are provided
which relate to the source, and at some point in the function transfer
to the target. This pattern is difficult to reason about and does not
provide any actual computational advantage, as the fields invariably get
re-allocated as part of the process anyway.
MeshToMesh no longer stores the cutting patches. The set of cutting
patches is not needed anywhere except at the point of mapping a field,
so it is now supplied to the mapping functions as an argument.
The meshToMesh topology changer no longer supports cutting patch
information. This did not previously work. Cutting patches either get
generated as calculated, or they require a pre-existing field to specify
their boundary condition. Neither of these options is suitable for a
run-time mesh change.
More code has been shared with patchToPatch, reducing duplication.
MRF requires mapping from a given set of polyMesh cells and faces to
internal and boundary faces of the finite volume system. It therefore
has to use the polyBFacePatches and polyBFacePatchFaces maps in order to
be compatible with NCC. This has been implemented, and now MRF should be
fully compatible with NCC.
Solvers ensure fluxes are maintained and updated correctly after topology change
and it no longer the responsibility of fvMeshTopoChangersRefiner to attempt
this.
The '-region' option has been leveraged to significantly simplify the
meshing and decomposition in the movingCone cases. These cases have also
been corrected to restore the variation in decomposition between the
different meshes, which is important for thoroughly testing the patch
field mapping. The shockFluid case has also had its duration extended a
little in order to span the final mesh mapping time.
The method to update phi in PDRFoamAutoRefine has been superseded by rhoUf in
all other compressible solvers and PDRFoam needs to be updated, requiring
funding. PDRFoamAutoRefine is no longer maintained.
The patch field 'autoMap' and 'rmap' functions have been replaced with a
single 'map' function that can used to do any form of in-place
patch-to-patch mapping. The exact form of mapping is now controlled
entirely by the mapper object.
An example 'map' function is shown below:
void nutkRoughWallFunctionFvPatchScalarField::map
(
const fvPatchScalarField& ptf,
const fvPatchFieldMapper& mapper
)
{
nutkWallFunctionFvPatchScalarField::map(ptf, mapper);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
mapper(Ks_, nrwfpsf.Ks_);
mapper(Cs_, nrwfpsf.Cs_);
}
This single function replaces these two previous functions:
void nutkRoughWallFunctionFvPatchScalarField::autoMap
(
const fvPatchFieldMapper& m
)
{
nutkWallFunctionFvPatchScalarField::autoMap(m);
m(Ks_, Ks_);
m(Cs_, Cs_);
}
void nutkRoughWallFunctionFvPatchScalarField::rmap
(
const fvPatchScalarField& ptf,
const labelList& addr
)
{
nutkWallFunctionFvPatchScalarField::rmap(ptf, addr);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
Ks_.rmap(nrwfpsf.Ks_, addr);
Cs_.rmap(nrwfpsf.Cs_, addr);
}
Calls to 'autoMap' should be replaced with calls to 'map' with the same
mapper object and the patch field itself provided as the source. Calls
to 'rmap' should be replaced with calls to 'map' by wrapping the
addressing in a 'reverseFvPatchFieldMapper' (or
'reversePointPatchFieldMapper') object.
This change simplifies the creation of new patch fields and hence
improves extensibility. It also provides more options regarding general
mapping strategies between patches. Previously, general abstracted
mapping was only possible in 'autoMap'; i.e., from a patch to itself.
Now, general mapping is possible between different patches.
Replacing volRegion removes unnecessary functionality duplication and ensures
cell set selection is consistent between functionObjects, fvModels and
fvConstraints for user convenience and reducing the code maintenance overhead.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c select entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
select entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
select all;
// Apply within a given cellSet
select cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
select cellZone; // Optional
cellZone rotor;
// Apply in cells containing a list of points
select points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
This is an optimisation control that allows the user to specify whether
or not mapping is re-calculated as a result of mesh motion. It is true
by default, as this is guaranteed to work in all scenarios.
Setting this control to false will provide computational benefit for
cases in which mapped patches move consistently, but if the patches do
not move consistently then it will result in incorrect behaviour.
Mesh motion is now supported in solid regions, but with the restriction
that it must be a solid-body-type motion. The mesh must not deform; all
cell volumes and face area magnitudes must remain constant. An error
will be generated if a motion strategy is selected that does not obey
this constraint.
The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
This is a more intuitive keyword than "funcName" or "entryName". A
function object's name and corresponding output directory can now be
renamed as follows:
#includeFunc patchAverage
(
name=cylinderT, // <-- was funcName=... or entryName=...
region=fluid,
patch=fluid_to_solid,
field=T
)
Some packaged functions previously relied on a "name" argument that
related to an aspect of the function; e.g., the name of the faceZone
used by the faceZoneFlowRate function. These have been disambiguated.
This has also made them consistent with the preferred input syntax of
the underlying function objects.
Examples of the changed #includeFunc entries are shown below:
#includeFunc faceZoneAverage
(
faceZone=f0, // <-- was name=f0
U
)
#includeFunc faceZoneFlowRate
(
faceZone=f0 // <-- was name=f0
)
#includeFunc populationBalanceSizeDistribution
(
populationBalance=bubbles,
regionType=cellZone,
cellZone=injection, // <-- was name=injection
functionType=volumeDensity,
coordinateType=diameter,
normalise=yes
)
#includeFunc triSurfaceAverage
(
triSurface=mid.obj, // <-- was name=mid.obj
p
)
#includeFunc triSurfaceVolumetricFlowRate
(
triSurface=mid.obj // <-- was name=mid.obj
)
#includeFunc uniform
(
fieldType=volScalarField,
fieldName=alpha, // <-- was name=alpha
dimensions=[0 0 0 0 0 0 0],
value=0.2
)
