The icx and icpx Intel compilers are selected by
WM_COMPILER=Icx
These compilers are based on the Clang front-end and hence the configuration
files are based on and nearly identical to those for Clang.
Support for the new OneAPI compilers replaces the now deprecated Intel icc, icpc
compilers.
Packaged function objects can now be deployed equally effectively by
(a) using a locally edited copy of the configuration file, or by
(b) passing parameters as arguments to the global configuration file.
For example, to post-process the pressure field "p" at a single location
"(1 2 3)", the user could first copy the "probes" packaged function
object file to their system directory by calling "foamGet probes". They
could then edit the file to contain the following entries:
points ((1 2 3));
field p;
The function object can then be executed by the postProcess application:
postProcess -func probes
Or it can be called at run-time, by including from within the functions
section of the system/controlDict file:
#includeFunc probes
Alternatively, the field and points parameters could be passed as
arguments either to the postProcess application by calling:
postProcess -func "probes(points=((1 2 3)), p)"
Or by using the #includeFunc directive:
#includeFunc probes(points=((1 2 3)), p)
In both cases, mandatory parameters that must be either edited or
provided as arguments are denoted in the configuration files with
angle-brackets, e.g.:
points (<points>);
Many of the packaged function objects have been split up to make them
more specific to a particular use-case. For example, the "surfaces"
function has been split up into separate functions for each surface
type; "cutPlaneSurface", "isoSurface", and "patchSurface". This
splitting means that the packaged functions now only contain one set of
relevant parameters so, unlike previously, they now work effectively
with their parameters passed as arguments. To ensure correct usage, all
case-dependent parameters are considered mandatory.
For example, the "streamlines" packaged function object has been split
into specific versions; "streamlinesSphere", "streamlinesLine",
"streamlinesPatch" and "streamlinesPoints". The name ending denotes the
seeding method. So, the following command creates ten streamlines with
starting points randomly seeded within a sphere with a specified centre
and radius:
postProcess -func "streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)"
The equivalent #includeFunc approach would be:
#includeFunc streamlinesSphere(nPoints=10, centre=(0 0 0), radius=1)
When passing parameters as arguments, error messages report accurately
which mandatory parameters are missing and provide instructions to
correct the format of the input. For example, if "postProcess -func
graphUniform" is called, then the code prints the following error message:
--> FOAM FATAL IO ERROR:
Essential value for keyword 'start' not set
Essential value for keyword 'end' not set
Essential value for keyword 'nPoints' not set
Essential value for keyword 'fields' not set
In function entry:
graphUniform
In command:
postProcess -func graphUniform
The function entry should be:
graphUniform(start = <point>, end = <point>, nPoints = <number>, fields = (<fieldNames>))
file: controlDict/functions/graphUniform from line 15 to line 25.
As always, a full list of all packaged function objects can be obtained
by running "postProcess -list", and a description of each function can
be obtained by calling "foamInfo <functionName>". An example case has
been added at "test/postProcessing/channel" which executes almost all
packaged function objects using both postProcess and #includeFunc. This
serves both as an example of syntax and as a unit test for maintenance.
The fieldsExpression function has been generalised to work with a
general operator. Existing functions "add" and "subtract" have been made
to use this system, and two new operations, "multiply" and "divide",
have been added.
The functions can now handle multiple types in both input and output. A
multiply (outer product) operation on two vectors and a scalar will
result in a tensor. If the operation chain is not supported (e.g.,
division by a vector) then a warning will be generated.
In addition, a "uniform" function has been added, which will create a
uniform geometric field of a given type with specified dimensions and
calculated boundary conditions. This is mostly useful for testing
purposes and for conveniently creating simple input fields for the
operation functions described above. The function can be called by
postProcess as follows:
postProcess -func "uniform(fieldType=volScalarField, name=length, dimensions=[m], value=2)"
A number of changes have been made to the surfaceFieldValue and
volFieldValue function objects to improve their usability and
performance, and to extend them so that similar duplicate functionality
elsewhere in OpenFOAM can be removed.
Weighted operations have been removed. Weighting for averages and sums
is now triggered simply by the existence of the "weightField" or
"weightFields" entry. Multiple weight fields are now supported in both
functions.
The distinction between oriented and non-oriented fields has been
removed from surfaceFieldValue. There is now just a single list of
fields which are operated on. Instead of oriented fields, an
"orientedSum" operation has been added, which should be used for
flowRate calculations and other similar operations on fluxes.
Operations minMag and maxMag have been added to both functions, to
calculate the minimum and maximum field magnitudes respectively. The min
and max operations are performed component-wise, as was the case
previously.
In volFieldValue, minMag and maxMag (and min and mag operations when
applied to scalar fields) will report the location, cell and processor
of the maximum or minimum value. There is also a "writeLocation" option
which if set will write this location information into the output file.
The fieldMinMax function has been made obsolete by this change, and has
therefore been removed.
surfaceFieldValue now operates in parallel without accumulating the
entire surface on the master processor for calculation of the operation.
Collecting the entire surface on the master processor is now only done
if the surface itself is to be written out.
The generation script has also been modified slightly to prevent empty
entries being generated for scripts with no options; e.g., the scripts
in $WM_PROJECT_DIR/bin that report a change in application name
When using 'simple' or 'hierarchical' decomposition it is useful to slightly rotate a
coordinate-aligned block-mesh to improve the processor boundaries by avoiding
irregular cell distribution at those boundaries. The degree of slight rotation
is controlled by the 'delta' coefficient and a value of 0.001 is generally
suitable so to avoid unnecessary clutter in 'decomposeParDict' 'delta' now
defaults to this value.
The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
This new constraint type is preferable to the 'empty' type used previously as it
support patch field values for post-processing and other purposes.
The internalFvPatchField operates as a 'zeroGradient' type so that the adjacent
cell values are displayed on the faces exposed by the sub-setting.
The internalFvsPatchField operates as a 'calculated' type so that the internal
face values are displayed on the faces exposed by the sub-setting.
The immediate benefit of this change can be seen when using 'subsetMesh' without
the '-noFields' option to create and write a sub-set of an 'fvMesh' with field
values, now the face values of the 'exposed' internal faces can be visualised.
the previous naming tan1, tan2, normal was non-intuitive and very confusing.
It was not practical to maintain backward compatibility but all tutorials and
example refineMeshDict files have been updated to provide examples of the
change.
The inside or outside region refinement level is now specified using the simple
"level <level>" entry in refinementRegions e.g.
refinementRegions
{
refinementBox
{
mode inside;
level 5;
}
}
rather than
refinementRegions
{
refinementBox
{
mode inside;
levels ((1E15 5));
}
}
where the spurious "1E15" number is not used and the '((...))' is unnecessary clutter.
The fireFoam solver has solver has been replaced by the more general
buoyantReactingFoam solver, which supports buoyant compressible reacting flow
coupled to multiple run-time-selectable lagrangian clouds and surface film
modelling and optional hydrostatic initialisation of the pressure and p_rgh.
Hydrostatic initialisation of the pressure fields is useful for large fires in
open domains where the stability of the initial flow is dominated by the initial
pressure distribution in the domain and at the boundaries. The optional
hydrostaticInitialization switch in fvSolution/PIMPLE with
nHydrostaticCorrectors enables hydrostatic initialisation, e.g.
PIMPLE
{
momentumPredictor yes;
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
}
and the resulting ph_rgh field can be used with the prghTotalHydrostaticPressure
p_rgh boundary condition to apply this hydrostatic pressure distribution at the
boundaries throughout the simulation.
See the following cases for examples transferred from fireFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/RAS
With the new fvModels framework it is now possible to implement complex models
and wrappers around existing complex models which can then be optionally
selected in any general solver which provides compatible fields and
thermophysical properties. This simplifies code development and maintenance by
significantly reducing complex code duplication and also provide the opportunity
of running these models in other solvers without the need for code duplication
and alteration.
The immediate advantage of this development is the replacement of the
specialised Lagrangian solvers with their general counterparts:
reactingParticleFoam -> reactingFoam
reactingParcelFoam -> reactingFoam
sprayFoam -> reactingFoam
simpleReactingParticleFoam -> reactingFoam
buoyantReactingParticleFoam -> buoyantReactingFoam
For example to run a reactingParticleFoam case in reactingFoam add the following
entries in constant/fvModels:
buoyancyForce
{
type buoyancyForce;
}
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
which add the acceleration due to gravity needed by Lagrangian clouds and the
clouds themselves.
See the following cases for examples converted from reactingParticleFoam:
$FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian
and to run a buoyantReactingParticleFoam case in buoyantReactingFoam add the
following entry constant/fvModels:
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
to add support for Lagrangian clouds and/or
surfaceFilm
{
type surfaceFilm;
libs ("libsurfaceFilmModels.so");
}
to add support for surface film. The buoyancyForce fvModel is not required in
this case as the buoyantReactingFoam solver has built-in support for buoyancy
utilising the p_rgh formulation to provide better numerical handling for this
force for strongly buoyancy-driven flows.
See the following cases for examples converted from buoyantReactingParticleFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian
All the tutorial cases for the redundant solvers have been updated and converted
into their new equivalents and redirection scripts replace these solvers to
provide users with prompts on which solvers have been replaced by which and
information on how to upgrade their cases.
To support this change and allow all previous Lagrangian tutorials to run as
before the special Lagrangian solver fvSolution/PIMPLE control
solvePrimaryRegion has been replaced by the more general and useful controls:
models : Enable the fvModels
thermophysics : Enable thermophysics (energy and optional composition)
flow : Enable flow (pressure/velocity system)
which also replace the fvSolution/PIMPLE control frozenFlow present in some
solvers. These three controls can be used in various combinations to allow for
example only the fvModels to be evaluated, e.g. in
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian/rivuletPanel
PIMPLE
{
models yes;
thermophysics no;
flow no;
.
.
.
so that only the film is solved. Or during the start-up of a case it might be
beneficial to run the pressure-velocity system for a while without updating
temperature which can be achieved by switching-off thermophysics. Also the
behaviour of the previous frozenFlow switch can be reproduced by switching flow
off with the other two switches on, allowing for example reactions, temperature
and composition update without flow.
The themo tables used in wallBoiling have had their Cp/Cv values
corrected, and have been coarsened and reduced in size to bound only the
operating point of the wallBoiling tutorials. They have also been moved
to $FOAM_TUTORIALS/resources/thermoData.
The correction to thermophysical properties has improved the stability
of these cases. As a result it has been possible to reduce the amount of
under-relaxation used in the wall modelling.
This makes usage of transformPoints the same as for
surfaceTransformPoints. Transformations are supplied as a string and are
applied in sequence.
Usage
transformPoints "\<transformations\>" [OPTION]
Supported transformations:
- "translate=<translation vector>"
Translational transformation by given vector
- "rotate=(<n1 vector> <n2 vector>)"
Rotational transformation from unit vector n1 to n2
- "Rx=<angle [deg] about x-axis>"
Rotational transformation by given angle about x-axis
- "Ry=<angle [deg] about y-axis>"
Rotational transformation by given angle about y-axis
- "Rz=<angle [deg] about z-axis>"
Rotational transformation by given angle about z-axis
- "Ra=<axis vector> <angle [deg] about axis>"
Rotational transformation by given angle about given axis
- "scale=<x-y-z scaling vector>"
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
transformPoints \
"translate=(-0.05 -0.05 0), \
Rz=45, \
translate=(0.05 0.05 0)"
Unused entries have been removed, and documentation provided for
previously undocumented entries has been added.
Patch contributed by Francesco Contino
The "initialSet" and "fuelSpecies" settings for chemistry reduction
methods now have to be formatted as lists, rather than dictionaries.
This is so that the settings in the TDAC configuration files can be
overridden in a case without the dictionaries being merged.
for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of chemistry model and solver selected in chemistryProperties
is not already compiled and present in the standard libraries for the selected
thermophysical properties the chemistry package will be constructed and compiled
automatically using the standard dynamicCode system provided in OpenFOAM.
The chemistry package is constructed automatically from the
etc/codeTemplates/dynamicCode/basicChemistryModel.* files, if these files do not
exist the standard chemistry lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the chemistry package is only
enabled if allowSystemOperations is set true.
for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo type,
fluidThermo, fluidReactionThermo etc. If the corresponding codeTemplates files
do not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo
type (e.g. fluidThermo), currently these are provided only for fluidThermo but
the others will be added shortly. If the corresponding codeTemplates files do
not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
