Both argument and value dimensions can be set for inline-constructable
function1-s. For example, this inline table function:
massFlowRate table [CAD] [g/s]
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
Is equivalent to this dictionary specification:
massFlowRate
{
type table;
xDimensions [CAD];
dimensions [g/s];
values
(
(0 0.46)
(0.17 1.9)
(0.31 4.8)
);
}
In the inline form, the argument/x-dimensions come first, and the value
dimensions second. If there only one dimension set provided, then this
is assumed to be the value dimensions.
The functionality necessary to write in a different unit set has been
removed. This was excessivelty complex, never used in practice, and of
little practical usage. Output numeric data, in general, is not designed
to be conveniently user-readable, so it is not important what unit
system it is written in.
The old fluid-specific rhoThermo has been split into a non-fluid
specific part which is still called rhoThermo, and a fluid-specific part
called rhoFluidThermo. The rhoThermo interface has been added to the
solidThermo model. This permits models and solvers that access the
density to operate on both solid and fluid thermophysical models.
The he*Thermo classes have been renamed to match their corresponding
basic thermo classes. E.g., rhoThermo now corresponds to RhoThermo,
rather than heRhoThermo.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
Lagrangian's dependency set is simpler than it used to be. There is no
longer a need to maintain a separate library for models that depend on
the momentum transport modelling.
Dictionary entries constructed with #calc and #codeStream can now
conveniently access and use typed variables. This means calculations
involving vectors and tensors and list and field types are now possible.
To access a variable and construct it as a given type within a #calc
or #codeStream entry, put the type immediately after the $ symbol inside
angled brackets <>. So, $<vector>var or $<vector>{var} substitutes a
variable named var as a vector.
Examples:
- Reflect a point in a plane defined by a normal
p (1 2 3);
n (1 1 0);
pStar #calc "$<vector>p - (2*sqr($<vector>n)/magSqr($<vector>n)&$<vector>p)";
- Rotate a list of points around an axis by a given angle
points ((3 0 0) (2 1 1) (1 2 2) (0 3 3));
rotation
{
axis (0 1 1);
angle 45;
}
#codeStream
{
codeInclude
#{
#include "pointField.H"
#include "transform.H"
#};
code
#{
const pointField points($<List<point>>points);
const vector axis = $<vector>!rotation/axis;
const scalar angle = degToRad($!rotation/angle);
os << "pointsRotated" << nl << (Ra(axis, angle) & points)() << ";";
#};
};
- Compute the centre and trianglation of a polygon
polygon ((0 0 0) (1 0 0) (2 1 0) (0 2 0) (-1 1 0));
#codeStream
{
codeInclude
#{
#include "polygonTriangulate.H"
#};
code
#{
const List<point> polygon($<List<point>>polygon);
writeEntry(os, "polygonCentre", face::centre(polygon));
polygonTriangulate triEngine;
triEngine.triangulate(polygon);
os << "polygonTris" << ' ' << triEngine.triPoints() << ";";
#};
};
- Generate a single block blockMeshDict for use with snappyHexMesh with no redundant information
min (-2.5 -1.2 -3.0); // Minimum coordinates of the block
max (2.5 1.2 3.0); // Maximum coordinates of the block
nCellsByL 33.3333; // Number of cells per unit length
// Calculate the number of cells in each block direction
nCells #calc "Vector<label>($nCellsByL*($<vector>max - $<vector>min) + vector::one/2)";
// Generate the vertices using a boundBox
vertices #codeStream
{
codeInclude
#{
#include "boundBox.H"
#};
code
#{
os << boundBox($<vector>min, $<vector>max).points();
#};
};
blocks
(
hex (0 1 2 3 4 5 6 7) $nCells simpleGrading (1 1 1)
);
defaultPatch
{
type patch;
}
boundary
();
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.
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.
If the libs entry is not provided and the name of the library containing the
functionObject, fvModel or fvConstraint corresponds to the type specified the
corresponding library is automatically loaded, e.g. to apply the
VoFTurbulenceDamping fvModel to an incompressibleVoF simulation the following
will load the libVoFTurbulenceDamping.so library automatically and instantiate
the fvModel:
turbulenceDamping
{
type VoFTurbulenceDamping;
delta 1e-4;
}
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.
The new general multi-region framework using the isothermalFilm and film solver
modules and executed with foamMultiRun is a much more flexible approach to the
inclusion of liquid films in simulations with the support for coupling to other
regions of various types e.g. gas flows, Lagrangian clouds, VoF, CHT etc. This
has all been achieved with a significant reduction in the number of lines of
code and significant improvements in code structure, readability and
maintainability.
foamToC: New run-time selection table of contents printing and interrogation utility
The new solver modules cannot provide the equivalent functionality of the -list
options available in the solver applications so foamToC has been developed as a
better, more general and flexible alternative, providing a means to print any or
all run-time selection tables in any or all libraries and search the tables for
any particular entries and print which library files the corresponding tables
are in, e.g.
foamToC -solver fluid -table fvPatchScalarField
Contents of table fvPatchScalarField, base type fvPatchField:
advective libfiniteVolume.so
calculated libfiniteVolume.so
codedFixedValue libfiniteVolume.so
codedMixed libfiniteVolume.so
compressible::alphatJayatillekeWallFunctionlibthermophysicalTransportModels.so
compressible::alphatWallFunction libthermophysicalTransportModels.so
compressible::thermalBaffle1D<eConstSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::thermalBaffle1D<ePowerSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::turbulentTemperatureCoupledBaffleMixedlibthermophysicalTransportModels.so
compressible::turbulentTemperatureRadCoupledMixedlibthermophysicalTransportModels.so
.
.
.
foamToC -solver fluid -search compressible::alphatWallFunction
compressible::alphatWallFunction is in tables
fvPatchField
fvPatchScalarField libthermophysicalTransportModels.so
and the very useful -allLibs option allows ALL libraries to be searched to find
in which table and which library file a particular model in in for example:
foamToC -allLibs -search phaseTurbulenceStabilisation
Loading libraries:
libtwoPhaseSurfaceTension.so
libcv2DMesh.so
libODE.so
.
.
.
phaseTurbulenceStabilisation is in tables
fvModel libmultiphaseEulerFoamFvModels.so
Application
foamToC
Description
Run-time selection table of contents printing and interrogation.
The run-time selection tables are populated by the optionally specified
solver class and any additional libraries listed in the \c -libs option or
all libraries using the \c -allLibs option. Once populated the tables can
be searched and printed by a range of options listed below. Table entries
are printed with the corresponding library they are in to aid selection
and the addition of \c libs entries to ensure availability to the solver.
Usage
\b foamToC [OPTION]
- \par -solver \<name\>
Specify the solver class
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries to load
- \par -allLibs
Load all libraries
- \par switches,
List all available debug, info and optimisation switches
- \par all,
List the contents of all the run-time selection tables
- \par tables
List the run-time selection table names (this is the default action)
- \par table \<name\>
List the contents of the specified table or the list sub-tables
- \par search \<name\>
Search for and list the tables containing the given entry
- \par scalarBCs,
List scalar field boundary conditions (fvPatchField<scalar>)
- \par vectorBCs,
List vector field boundary conditions (fvPatchField<vector>)
- \par functionObjects,
List functionObjects
- \par fvModels,
List fvModels
- \par fvConstraints,
List fvConstraints
Example usage:
- Print the list of scalar boundary conditions (fvPatchField<scalar>)
provided by the \c fluid solver without additional libraries:
\verbatim
foamToC -solver fluid -scalarBCs
\endverbatim
- Print the list of RAS momentum transport models provided by the
\c fluid solver:
\verbatim
foamToC -solver fluid -table RAScompressibleMomentumTransportModel
\endverbatim
- Print the list of functionObjects provided by the
\c multicomponentFluid solver with the libfieldFunctionObjects.so
library:
\verbatim
foamToC -solver multicomponentFluid \
-libs '("libfieldFunctionObjects.so")' -functionObjects
\endverbatim
- Print a complete list of all run-time selection tables:
\verbatim
foamToC -allLibs -tables
or
foamToC -allLibs
\endverbatim
- Print a complete list of all entries in all run-time selection tables:
\verbatim
foamToC -allLibs -all
\endverbatim
These additions mean that the volume-weighted average or volume integral
of a field can be conveniently post-processed. This can be done
interactively using foamPostProcess:
foamPostProcess -func "volAverage(U)"
foamPostProcess -func "volIntegrate(rho)"
Or at run-time by adding to the functions sub-section of the
controlDict:
#includeFunc volAverage(U)
#includeFunc volIntegrate(rho)
compressibleVoF supports cavitation fvModels which provide a more physical and
controllable approach to cavitation modelling than the simple homogeneous
equilibrium approximation used in cavitatingFoam.
The tutorials/multiphase/cavitatingFoam/RAS/throttle case has been converted to
tutorials/modules/compressibleVoF/throttle which demonstrates how to update
cases from cavitatingFoam to compressibleVoF.
A cavitatingFoam script is provided to redirect users to update their cases to
compressibleVoF.
The codedFunctionObjectTemplate is based on regionFunctionObject requiring
fvMesh.H and most manipulate volFields so it makes sense for volFields.H to be
included by default.
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.
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
)
The moleFractions function has been simplified and generalised. It no
longer needs to execute on construction, as function objects now have
the ability to execute at the start of a simulation. It can also now
construct a thermo model if none exists, simplifying its use as a post
processing operation. A packaged function has been provided, so that all
that is needed to execute the function is the following setting in the
functions section of the system/controlDict:
#includeFunc moleFractions
Alternatively, it can be executed on the command line as follows:
foamPostProcess -func moleFractions
A new massFractions function has also been added which converts mole
fraction fields (e.g., X_CH4, X_O2, etc...), or moles fields (n_CH4,
n_O2, etc...) to the corresponding mass fraction fields. This function,
by contrast to the moleFractions function described above, should not be
used at run-time. It should only be used to initialise a simulation in
which molar data is known and needs converting to mass-fractions. If at
the point of execution a thermo model exists, or mass-fraction fields
are found on disk, then this function will exit with an error rather
than invalidating the existing mass-fraction data. Packaging is provided
that allows the function to be executed to initialise a case as follows:
foamPostProcess -func massFractions
