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.
functionObjects layerAverage, nearWallFields, wallHeatFlux, wallHeatTransferCoeff,
wallShearStress and forcesBase now support both the 'patches' option for which a
list of regular expressions to select the patches is specified and the new simple
'patch' option for which a single patch name is specified.
These files are now searched for starting at the current time and back in time
to constant but stopping at the most recent polyMesh directory containing faces,
i.e. the most recent topological specification of the mesh. Zones which cannot
be found are set empty rather than requiring zone files to be present containing
an empty list.
