This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
Following this improvement the null-constructors have been removed from all
pointPatchFields not added to the null-constructor table thus reducing the
amount of code and maintenance overhead and making easier and more obvious to
write new pointPatchField types.
gcc-13 has new code checking and warning mechanisms which are useful but not
entirely robust and produce many false positives, particularly with respect to
local references:
warning: possibly dangling reference to a temporary
This commit resolves many of the new warning messages but the above false
warnings remain. It is possible to switch off this warning but as it also
provides some useful checks it is currently left on.
This change relaxes the previous restriction that mappedWall patches
cannot have transformation. It permits cyclic multi-region simulations
in which the cyclic plane lies on the interface between regions.
The mappedWall still differs from the mapped patch in that it is assumed
to be untransformed unless a transformation is explicitly specified. The
mapped patch, by contrast, will attempt to automatically calculate a
transformation from the geometry of the patches in the same way as is
done for cyclics.
This completes commit 381e0921 and permits patches on the "top" of
extruded regions to determine the point locations opposite as well as
the face centres and areas. This means that patches with dissimilar
meshes can now be coupled via the patchToPatch interpolation engine.
A few fixes have also been applied to extrudeToRegionMesh to make the
intrude option compatibile with extrusion into internal faces and
between opposing zones/sets/patches. The 'shadow' entries used for
extrusion inbetween opposing zones/sets/patches have also been renamed
to 'opposite' for consistency with the patch names and patch types
entries; e.g.,
faceZones (fz1 fz3);
oppositeFaceZones (fz2 fz4); // <-- was 'faceZonesShadow'
faceSets (fs1 fs3);
oppositeFaceSets (fs2 fs4); // <-- was 'faceSetsShadow'
patches (p1 p3);
oppositePatches (p2 p4); // <-- was 'patchesShadow'
The cell-owns-face information is determined by comparing edges of
adjacent faces, starting from a given seed face for which ownership is
known. This calculation walks now the cell in order to be sure that all
faces have had their ownership determined.
Previously the algorithm just iterated over the faces and face-edges.
This spans the entire cell most of the time, but for large polyhedra a
single pass may not propagate the necessary information across the
entire cell. This could be fixed by doing multiple passes until all
faces have been visited, but a walk is likely to be cheaper as it is not
wasting effort iterating over the same faces multiple times.
This change fixes some failures associated with the isoSurface
algorithm. Occasionally, a cut plane or similar could be seen to be
missing one or two faces. These faces were associated with complex
polyhedra on which the cell-owns-face information had been
miscalculated. Surfaces should now be complete and contiguous.
This fixes situations in which the mapping is used between a region with
a changing mesh and a region with a non-changing mesh, and where the
non-changing-mesh region owns the mapping. It ensures that changes in
the changing-mesh region trigger re-generation of the mapping in the
adjacent non-changing-mesh region.
mappedFilmPressureFvPatchScalarField is derived from the new mappedFvPatchField
base-class for mapped patch fields including mappedValueFvPatchField.
Class
Foam::mappedFilmPressureFvPatchScalarField
Description
Film pressure boundary condition which maps the neighbouring fluid patch
pressure to both the surface patch and internal film pressure field.
This fvModel applies a mass source to the continuity equation and to all
field equations, in a zero-dimensional case. Correction is made to
account for the mass that exits the domain due to expansion in space, so
that the model correctly applies a total mass flow rate. It is
implemented as a light wrapper around the massSource model.
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.
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.
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 option means that a one field can be mapped to another within the
same patch without specifying the patch name. E.g.:
walls
{
type mappedValue;
//neighbourPatch walls; // <-- Previously required. Still supported.
samePatch yes; // <-- New alternative specification
field T.liquid;
value $internalField;
}
This is useful when the boundary condition is specified using a regular
expression for the patch name.
"wall_.*"
{
type mappedValue;
//neighbourPatch ???; // <-- No unique name can be given
samePatch yes; // <-- Still works
field T.liquid;
value $internalField;
}
It is now possible to map from one field to another within the same
patch, using the mappedValue boundary condition. The restriction is that
the mapping must be from a different field, otherwise field values are
being assigned to themselves, which produces an undefined result.
The mappedValue boundary condition can now be used in place of the
copiedFixedValue condition in the multiphaseEuler module. The
copiedFixedValue condition has therefore been removed.
In addition, the error messages that result from casting a patch to its
mapping engine (mappedPatchBase) have been standardised, and made more
specific to the situation in which the mapping is applied. It may be
inappropriate, for example, to map within the same region or patch.
These cases are now identified and appropriate error messages are
generated.
The error messages have also been made IO errors, so they now provide
context with regards to the dictionary entries that they relate to.
Replaces MeshObject, providing a formalised method for creating demand-driven
mesh objects, optionally supporting update functions called by the mesh
following mesh changes.
Class
Foam::DemandDrivenMeshObject
Description
Templated abstract base-class for demand-driven mesh objects used to
automate their allocation to the mesh database and the mesh-modifier
event-loop.
DemandDrivenMeshObject is templated on the type of mesh it is allocated
to, the type of the mesh object (TopologicalMeshObject, GeometricMeshObject,
MoveableMeshObject, DistributeableMeshObject, UpdateableMeshObject) and the
type of the actual object it is created for example:
\verbatim
class leastSquaresVectors
:
public DemandDrivenMeshObject
<
fvMesh,
MoveableMeshObject,
leastSquaresVectors
>
{
.
.
.
//- Delete the least square vectors when the mesh moves
virtual bool movePoints();
};
\endverbatim
MeshObject types:
- TopologicalMeshObject: mesh object to be deleted on topology change
- GeometricMeshObject: mesh object to be deleted on geometry change
- MoveableMeshObject: mesh object to be updated in movePoints
- UpdateableMeshObject: mesh object to be updated in topoChange or
movePoints
- PatchMeshObject: mesh object to be additionally updated patch changes
DemandDrivenMeshObject should always be constructed and accessed via the New
methods provided so that they are held and maintained by the objectRegistry.
To ensure this use constructors of the concrete derived types should be
private or protected and friendship with the DemandDrivenMeshObject
base-class declared so that the New functions can call the the constructors.
Additionally the mesh-object types (TopologicalMeshObject, GeometricMeshObject,
MoveableMeshObject, DistributeableMeshObject, UpdateableMeshObject) can now be
used as mix-in types for normally allocated objects providing the same interface
to mesh-change update functions, see the Fickian fluid
thermophysicalTransportModel or anisotropic solid thermophysicalTransportModel.
This new approach to adding mesh-update functions to classes will be applied to
other existing classes and future developments to simplify the support and
maintenance of run-time mesh changes, in particular mesh refinement/unrefinement
and mesh-to-mesh mapping.
The timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
A set of routines for cutting polyhedra have been added. These can cut
polyhedral cells based on the adjacent point values and an iso-value
which defines the surface. The method operates directly on the
polyhedral cells; it does not decompose them into tetrahedra at any
point. The routines can compute the cut topology as well as integrals of
properties above and below the cut surface.
An iso-surface algorithm has been added based on these polyhedral
cutting routines. It is significantly more robust than the previous
algorithm, and produces compact surfaces equivalent to the previous
algorithm's maximum filtering level. It is also approximately 3 times
faster than the previous algorithm, and 10 times faster when run
repeatedly on the same set of cells (this is because some addressing is
cached and reused).
This algorithm is used by the 'isoSurface', 'distanceSurface' and
'cutPlane' sampled surfaces.
The 'cutPlane' sampled surface is a renaming of 'cuttingPlane' to make
it consistent with the corresponding packaged function. The name
'cuttingPlane' has been retained for backwards compatibility and can
still be used to select a 'cutPlane' surface. The legacy 'plane' surface
has been removed.
The 'average' keyword has been removed from specification of these
sampled surfaces as cell-centred values are no longer used in the
generation of or interpolation to an iso-surface. The 'filtering'
keyword has also been removed as it relates to options within the
previous algorithm. Zone support has been reinstated into the
'isoSurface' sampled surface. Interpolation to all these sampled
surfaces has been corrected to exactly match the user-selected
interpolation scheme, and the interpolation procedure no longer
unnecessarily re-generates data that is already available.
The nearest, matching and inverseDistance methods are now based on a
shared "nearby" method. This method creates, for each face, a local
stencil of opposing faces for which the bounding spheres overlap. This
has proven far more robust on cases with both conformal and
non-conformal interfaces.
This change prevents fatal errors occurring during programmatic
construction of a plane object. If an invalid plane is constructed then
this can be tested for using a new plane::valid() method.
Errors are still generated from dictionary construction as before, and
they have been improved to better identify where in the file the
erroneous specification is.
This change fixes some issues associated with meshToMesh mapping. The
cell overlap calculation now detects and skips over degenerate
tetrahedra. Previously, it was generating errors as it tried to
construct planes from the faces of these degenerate tetrahedra.
If checkMesh is executed with the -allGeometry option, then surface
files containing the NCC coverage will now be written out. Coverage is
the ratio between coupled area magnitude and total area magnitude. This
is useful for locating parts of the boundary mesh that are in error.
Errors (such as folds and pinches) typically manifest as a coverage
value that deviates significantly from a value of one.
This is comparable to the writing of AMI patches's weight sums, which
also used to occur when the -allGeometry option was selected.
to handle isotropic and anisotropic is a consistent, general and extensible
manner, replacing the horrible hacks which were in solidThermo.
This is entirely consistent with thermophysicalTransportModel for fluids and
provides the q() and divq() for the solid energy conservation equations. The
transport model and properties are specified in the optional
thermophysicalTransport dictionary, the default model being isotropic if this
dictionary file is not present, thus providing complete backward-compatibility
for the common isotropic cases.
Anisotropic thermal conductivity is now handled in a much more general manner by
the anisotropic model:
Class
Foam::solidThermophysicalTransportModels::anisotropic
Description
Solid thermophysical transport model for anisotropic thermal conductivity
The anisotropic thermal conductivity field is evaluated from the solid
material anisotropic kappa specified in the physicalProperties dictionary
transformed into the global coordinate system using default
coordinate system and optionally additional coordinate systems specified
per-zone in the thermophysicalProperties dictionary.
Usage
Example of the anisotropic thermal conductivity specification in
thermophysicalProperties with two zone-based coordinate systems in
addition to the default:
\verbatim
model anisotropic;
// Default coordinate system
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type cylindrical;
e3 (1 0 0);
}
}
// Optional zone coordinate systems
zones
{
coil1
{
type cartesian;
origin (0.1 0.2 0.7);
coordinateRotation
{
type cylindrical;
e3 (0.5 0.866 0);
}
}
coil2
{
type cartesian;
origin (0.4 0.5 1);
coordinateRotation
{
type cylindrical;
e3 (0.866 0.5 0);
}
}
}
\endverbatim
This development required substantial rationalisation of solidThermo,
coordinateSystems and updates to the solid solver module, solidDisplacementFoam,
the wallHeatFlux functionObject, thermalBaffle and all coupled thermal boundary
conditions.
