Also provide fields and curFields functions which return the list of registered
fields not including the geometryFields and current registered fields not
including the geometryFields or old-time fields to simplify mapping code for
NCC, mesh-to-mesh mapping and load-balancing.
The purpose of these operations was unclear, and there was no
documentation or examples of their usage. The differences between these
operations behaviours for scalar and vector input seemed arbitrary.
These operations have in some cases become the subject of confusion.
They have therefore been removed.
Equivalent functionality could be easily reinstated as and when a clear
need and application becomes apparent.
Specific names have been given for expand functions. Unused functions
have been removed, and functions only used locally have been removed
from the namespace. Documentation has been corrected. Default and
alternative value handling has been removed from code template
expansion.
setFormat no longer defaults to the value of graphFormat optionally set in
controlDict and must be set in the functionObject dictionary.
boundaryFoam, financialFoam and pdfPlot still require a graphFormat entry in
controlDict but this is now read directly rather than by Time.
Class
Foam::functionObjects::checkMesh
Description
Executes primitiveMesh::checkMesh(true) every execute time for which the
mesh changed, i.e. moved or changed topology.
Useful to check the correctness of changing and morphing meshes.
Example of checkMesh specification:
\verbatim
checkMesh
{
type checkMesh;
libs ("libutilityFunctionObjects.so");
executeControl timeStep;
executeInterval 10;
}
\endverbatim
or using the standard configuration file:
\verbatim
#includeFunc checkMesh(executeInterval=10)
\endverbatim
Can be used with any solver supporting mesh-motion, in particular the movingMesh
solver module, to check the mesh quality following morphing and/or topology
change.
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.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField 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 is useful to write results before a case fails due to uncontrollable
automatic time-step reduction, usually caused by unstable pressure-velocity
coupling.
Class
Foam::functionObjects::stopAtTimeStep
Description
Stops the run if the time-step drops below the specified value in seconds
and optionally write results before stopping.
The following actions are supported:
- noWriteNow
- writeNow (default)
- nextWrite
Examples of function object specification:
\verbatim
stop
{
type stopAtTimeStep;
libs ("libutilityFunctionObjects.so");
minDeltaT 1e-8;
action writeNow;
}
\endverbatim
will write the fields and stop if the time-step drops below 1e-8s.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtTimeStep | yes |
minDeltaT | Minimum time-step [s] | yes |
action | Action executed | no | writeNow
\endtable
It is now possible to calculate field values of VolInternalFields, e.g. the
cached kEpsilon:G field in the
tutorials/modules/incompressibleFluid/pitzDailySteady case:
#includeFunc cellMax(kEpsilon:G)
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
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);
}
Description
Solver module to execute the \c functionObjects for a specified solver
The solver specified by either the \c subSolver or if not present the \c
solver entry in the \c controlDict is instantiated to provide the physical
fields needed by the \c functionObjects. The \c functionObjects are then
instantiated from the specifications are read from the \c functions entry in
the \c controlDict and executed in a time-loop also controlled by entries in
\c controlDict and the \c maxDeltaT() returned by the sub-solver.
The fields and other objects registered by the sub-solver are set to
NO_WRITE as they are not changed by the execution of the functionObjects and
should not be written out each write-time. Fields and other objects created
and changed by the execution of the functionObjects are written out.
solvers::functions in conjunction with the scalarTransport functionObject
replaces scalarTransportFoam and provide more general handling of the scalar
diffusivity.
This function stops the run when all parcel clouds are empty.
Example of function object specification:
stop
{
type stopAtEmptyClouds;
libs ("liblagrangianFunctionObjects.so");
executeControl timeStep; // <-- Likely only to be needed if injection
startTime 0.500001; // starts after time zero. In which case the
// startTime should be slightly after the
// injection start time.
action nextWrite;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
stopAtEmptyClouds(startTime=0.500001)
Support for mesh sub-cycling has been removed from Lagrangian. Various
Lagrangian processes already support sub-dividing the time-step. It is
easier and more efficient to extend that support all the way to the
high-level cloud objects, rather than to sub-cycle the mesh.
This has additional benefits. The cloud now no longer needs to reset the
step fraction at the start of every sub-motion. Injection can take
advantage of this by modifying particles' step fractions in order to
distribute them uniformly through the time-step. This is a simple and
efficient method. Previously, injection would track the particles some
distance after injection. This was more expensive to do, it resulted in
spatial artefacts in the injected Lagrangian field, and it did not
correctly handle interactions with patches or parallel transfers.
The lack of injection tracking also means that particles injected
through patches now start their simulation topologically connected to
the face on which they are created. This means that they correctly
trigger cloud functions associated with that face and/or patch.
The injection models now also return barycentric coordinates directly,
rather than the global position of injected particles. For methods that
initially generate locations naturally in terms of barycentric
coordinates, this prevents unnecessary and potentially fragile
conversion from barycentric to Cartesian and back again. These are
typically the methods that "fill" some sort of space; e.g., patch or
cell-zone injections.
This function object writes graphs of patch face values, area-averaged in
planes perpendicular to a given direction. It adaptively grades the
distribution of graph points to match the resolution of the mesh.
Example of function object specification:
patchCutLayerAverage1
{
type patchCutLayerAverage;
libs ("libpatchCutLayerAverageFunctionObject.so");
writeControl writeTime;
writeInterval 1;
patch lowerWall;
direction (1 0 0);
nPoints 100;
interpolate no;
fields (p U);
axis x;
setFormat raw;
}
A packaged function object is also included, which permits the following
syntax to be used, either with #includeFunc in the system/controlDict,
or with the -func option to foamPostProcess:
graphPatchCutLayerAverage
(
funcName=aerofoilLowerPressure,
patch=aerofoilLower,
direction=(0.15 -0.016 0),
nPoints=100,
p
)
The fieldAverage can now average fields that do not exist at
construction time, and it also supports restart on cases in which
the mesh topology is changing.
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.
Also changed the keyword timeVsFile to the more logical fileVsTime with
backward-compatibility.
Class
Foam::functionObjects::timeActivatedFileUpdate
Description
Performs a file copy/replacement once a specified time has been reached.
Usage
Example usage to update the fvSolution dictionary at 0.1, 0.2 and 0.3s
during the run:
\verbatim
fileUpdate1
{
type timeActivatedFileUpdate;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
fileToUpdate "$FOAM_CASE/system/fvSolution";
fileVsTime
(
(-1 "$FOAM_CASE/system/fvSolution.0")
(0.10 "$FOAM_CASE/system/fvSolution.10")
(0.20 "$FOAM_CASE/system/fvSolution.20")
(0.35 "$FOAM_CASE/system/fvSolution.35")
);
}
\endverbatim
Resolves bug-report https://bugs.openfoam.org/view.php?id=3938
Now that kappa, Cp and Cv fields are cached and Cpv returns either the Cp or Cv
field reference depending on the energy solved and thermal transport is now
fundamentally based on temperature rather energy gradients it is no longer
necessary or useful to provide an abstract function returning alphahe.
The thermodynamic density field is now named "rho" by default and only renamed
"thermo:rho" by solvers that create and maintain a separate continuity density
field which is named "rho". This change significantly simplifies and
standardises the specification of schemes and boundary conditions requiring
density as it is now always named "rho" or "rho.<phase>" unless under some very
unusual circumstances the thermodynamic rather than continuity density is
required for a solver maintaining both.
The advantage of this change is particularly noticeable for multiphase
simulations in which each phase has its own density now named "rho.<phase>"
rather than "thermo:rho.<phase>" as separate phase continuity density fields are
not required so for multiphaseEulerFoam the scheme specification:
"div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)" Gauss limitedLinear 1;
is now written:
"div\(alphaRhoPhi.*,\(p\|rho.*\)\)" Gauss limitedLinear 1;
the new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
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.
so that the specification of time-step and write-interval are in user-time,
consistent with the controlDict.
Class
Foam::functionObjects::setTimeStepFunctionObject
Description
Updates the time step as a Function1 of time.
If the case is running with userTime specified in controlDict then the
time-step values returned by the Function1 are assumed to be in user-time
rather than real-time.
Class
Foam::functionObjects::setWriteIntervalFunctionObject
Description
Updates the writeInterval as a Function1 of time.
If the case is running with userTime specified in controlDict then the write
interval values returned by the Function1 are assumed to be in user-time
rather than real-time.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3904
Function objects now write to the following path when applied to a
non-default region of a multi-region case:
postProcessing/<regionName>/<functionName>/<time>/
Previously the order of <regionName> and <functionName> was not
consistent between the various function objects.
Resolves bug report https://bugs.openfoam.org/view.php?id=3907
This reference represents unnecessary storage. The mesh can be obtained
from tracking data or passed to the particle evolution functions by
argument.
In addition, removing the mesh reference makes it possible to construct
as particle from an Istream without the need for an iNew class. This
simplifies stream-based transfer, and makes it possible for particles to
be communicated by a polyDistributionMap.
