The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
The alpha equation in this model has been changed to a d2dt2 scheme,
rather than a hard-coded correction on a ddt scheme that relies on the
old-time value remaining unchanged from the previous timestep. This
modification makes the model compatible with some forms of mesh change.
The 'featureAngle' control defines the included angle between faces
above which layer extrusion is prevented. Its use within snappyHexMesh
was incorrect in that the cosine was not being taken before being
compared to dot products of face normals. This has now been corrected.
Existing 'featureAngle' settings may need changing to recover equivalent
behaviour. Any angle previously set to 58 degrees or above previously
resulted in no reduction of layer coverage. A large angle between 90 and
180 degrees is likely to be an appropriate replacement for cases such as
this. Angles previously set to 57 degrees and below can be equivalently
replaced by a value of (180/pi)*arccos(<angle>*(pi/180)).
Note that changing the feature angle also affects the slip feature
angle. The slip feature angle is taken to be half the feature angle if a
'slipFeatureAngle' is not specified.
lookupCompoundScoped is used by dictionary via stringOps to provide fast access
to compound tokens without the need to construct the container for every access,
e.g.
listU List<vector> ((1.1 2.1 1.1) (2.1 3.2 4.1) (4.3 5.3 0));
magU1 #calc "mag($listU[1])";
magU2 #calc "mag($listU[2])";
where the listU is declared as a List<vector> compound token which is then
accessed directly by $listU without the need to specify the type and the data is
accessed directly by reference which is more efficient, particularly if the list
is large.
The new token::typeName() function is used in stringOps to provide dictionary
with better support for automatic type inference for variables in #calc
expressions.
This change corrects some of the logic governing whether a geometry is
determined to result in a valid intersection or not. It has fixed some
issues with regards to intersections being erroneously duplicated or
omitted and has thereby increased the proportion of intersections that
result in unity or near-unity coverage.
Cloud functions are now not created at all during foamPostProcess. These
functions mostly usually compute state during tracking, so they cannot
produce anything useful when run as a post-process. In addition, in a
few cases, their initialisation can overwrites valid post-processing
files created at run-time.
A more "complete" system might distinguish between the few cloud
functions that can be evaluated instantaneously (e.g., sizeDistribution,
relativeVelocity, ...) and those those that cannot (e.g., fluxes,
patchCollisionDensity, ...) and only construct and execute the former
within foamPostProcess. This could be achieved with appropriate
support/funding.
In addition, volFieldValue and surfaceFieldValue have been modified so
that they do not write anything if no fields are available. This also
prevents the overwriting of valid run-time results in some cases.
The coefficients in the polynomial are now specified in order of
increasing exponent, starting from the constant coefficient (i.e., zero
exponent). Exponents are no longer specified. This better fits the
definition of a polynomial, and it prevents the strange scenario when if
exponents are given as a vector or tensor or similar then the units of
the coefficients are not the same across the different components.
For example, polynomial y = -1 + x^2 + 2x^3 can be specified as:
<name> polynomial (-1 0 1 2);
Or, alternatively:
<name>
{
type polynomial;
coeffs (-1 0 1 2);
}
Both these boundary conditions now support specification of the radial
and tangential components as a function of time and radius, or
alternatively the tangential component as a time-varying rotational
speed.
The cylindricalInletVelocity condition has been superseeded by
swirlInletVelocity and has therefore been removed.
The 'function1' function returns the result of a Function1 using just
one of the arguments given to the function2. The function1 is specified
as value1 or value2, depending on which argument it is to be evaluated
with. E.g.:
<name>
{
type function1;
value2 table
(
(0.00 (0 0 0))
(0.35 (0 0 1))
(0.71 (0 0 0))
);
}
The 'product' function returns the product of two independent
Function1-s of the two input arguments, again specified as value1 and
value2. For example, to scale a table of vectors in the first argument
with a ramp in the second argument:
<name>
{
type product;
value1<vector> table
(
(0.00 (0 0 0))
(0.25 (1 0 0))
(0.50 (0 0 0))
);
value2<scalar>
{
type linearRamp;
start 1;
duration 4;
}
}
Note that only one type specification (the <vector>/<scalar>/... part)
is needed in general for the value entries, and no type specifications
are needed if the function is scalar.
The 'radial' function returns a Function1 of the magnitude of the
two-dimensional vector with components equal to the input arguments.
E.g.:
<name>
{
type radial;
value table
(
(0.00 (0 0 0))
(0.35 (0 0 1))
(0.71 (0 0 0))
);
}
to avoid clash with the set type, e.g. in topoSetDict
actions
(
{
action new;
type cellZoneSet;
name c0;
source shapeToCell;
shape hex;
}
);
the entry "shape hex" selects the hex cell shape.
The editor must be specified by configuring the EDITOR environment
variable. For example to use the 'gedit' editor, the following entry
could be added to the user's .bashrc file:
export EDITOR=gedit
corresponding to a give order, another case or another region.
Description
Utility to reorder the patches of a case
The new patch order may be specified directly as a list of patch names
following the -patchOrder option or from the boundary file of a reference
case specified using the -referenceCase option with or without the
-referenceRegion option.
This utility run either serial or parallel but either way the reference
case boundary file is read from the constant directory.
Usage
\b reorderPatches
Options:
- \par -patchOrder \<patch names\>
Specify the list of patch names in the new order.
- \par -referenceCase \<case path\>
Specify the reference case path
- \par -referenceRegion \<name\>
Specify an alternative mesh region for the reference case.
If -referenceCase is not specified the current case is used.
- \par -overwrite \n
Replace the old mesh with the new one, rather than writing the new one
into a separate time directory
- \par -region \<name\>
Specify an alternative mesh region.
