for consistency with fvModels and fvConstraints, to simplify code and case
maintenance and to avoid the potentially complex functions entries being
unnecessarily parsed by utilities for which functionObject evaluation is
disabled.
The functions entry in controlDict is still read if the functions file is not
present for backward-compatibility, but it is advisable to migrate cases to use
the new functions file.
The fact that these names create sources in their associated transport
equations is clear in context, so the name does not need to contain
'Source'.
Having 'Source' in the name is a historic convention that dates back to
when fvModels and fvConstraints were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
The full set of name changes is as follows:
accelerationSource -> acceleration
actuationDiskSource -> actuationDisk
effectivenessHeatExchangerSource -> effectivenessHeatExchanger
explicitPorositySource -> porosityForce
radialActuationDiskSource -> radialActuationDisk
rotorDiskSource -> rotorDisk
sixDoFAccelerationSource -> sixDoFAcceleration
solidEquilibriumEnergySource -> solidThermalEquilibrium
solidificationMeltingSource -> solidificationMelting
volumeFractionSource -> volumeBlockage
interRegionExplicitPorositySource -> interRegionPorosityForce
VoFSolidificationMeltingSource -> VoFSolidificationMelting
The old names are still available for backwards compatibility.
The fact that these names refer to constraints is clear in context, so
the name does not need to contain 'Constraint'.
Having 'Constraint' in the name is a historic convention that dates back
to when fvConstraints and fvModels were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
This change has been applied to the 'fixedValue' and 'fixedTemperature'
constraints, which were formerly named 'fixedValueConstraint' and
'fixedTemperatureConstraint', respectively.
The old names are still available for backwards compatibility.
Description
Specify an include file for #calc, expects a single string to follow.
For example if functions from transform.H are used in the #calc expression
\verbatim
angleOfAttack 5; // degs
angle #calc "-degToRad($angleOfAttack)";
#calcInclude "transform.H"
liftDir #calc "transform(Ry($angle), vector(0, 0, 1))";
dragDir #calc "transform(Ry($angle), vector(1, 0, 0))";
\endverbatim
The usual expansion of environment variables and other constructs
(eg, the \c ~OpenFOAM/ expansion) is retained.
See also:
Class
Foam::functionEntries::calcEntry
Description
Uses dynamic compilation to provide calculating functionality
for entering dictionary entries.
E.g.
\verbatim
a 1.0;
b 3;
c #calc "$a*$b";
\endverbatim
Note the explicit trailing 0 ('1.0') to force a to be read (and written)
as a floating point number.
Special care is required for calc entries that include a division since
"/" is also used as the scoping operator to identify keywords in
sub-dictionaries. For example, "$a/b" expects a keyword "b" within a
sub-dictionary named "a". A division can be correctly executed by using a
space between a variables and "/", e.g.
\verbatim
c #calc "$a / $b";
\endverbatim
or "()" scoping around the variable, e.g.
\verbatim
c #calc "($a)/$b";
\endverbatim
Additional include files for the #calc code compilation can be specified
using the #calcInclude entry, e.g. if functions from transform.H are used
\verbatim
angleOfAttack 5; // degs
angle #calc "-degToRad($angleOfAttack)";
#calcInclude "transform.H"
liftDir #calc "transform(Ry($angle), vector(0, 0, 1))";
dragDir #calc "transform(Ry($angle), vector(1, 0, 0))";
\endverbatim
Note:
Internally this is just a wrapper around codeStream functionality - the
#calc string is used to construct a dictionary for codeStream.
Simplifications have been made where possible, as permitted by the new
$<type>var syntax. Duplication has been reduced in similar blockMesh
files (e.g., sloshingTank cases). Settings that cannot practically be
changed have been hard-coded (e.g., angle in the mixerVessel2D
blockMeshDict). The rotor2D blockMeshDict has been centralised and
extended to work with an arbitrary number of rotor blades.
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.
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.
