Whilst the cell values of non-solved species do not change, the boundary
values might, and correcting them is necessary for certain
post-processing operations to produce sensible results.
The fvModels directory has been reorganised into separate libraries to make it
easier to add and maintain new complex models such as the propellerDisk.
Class
Foam::fv::propellerDisk
Description
Disk momentum source which approximates a propeller based on a given
propeller curve.
Reference:
\verbatim
Hough, G. R., & Ordway, D. E. (1964).
The generalized actuator disk.
Developments in theoretical and applied mechanics, 2, 317-336.
\endverbatim
Usage
Example usage:
\verbatim
diskSource
{
type propellerDisk;
selectionMode cellZone;
cellZone propeller;
diskNormal (1 0 0); // Normal direction of the disk
n 26.03; // Rotation speed [1/s]
dPropeller 0.203; // Propeller diameter
dHub 0.039179; // Hub diameter
propellerCurve
{
type table;
// J Kt Kq
values
(
(0.10 (0.3267 0.03748))
(0.15 (0.3112 0.03629))
(0.20 (0.2949 0.03500))
(0.25 (0.2777 0.03361))
(0.30 (0.2598 0.03210))
(0.35 (0.2410 0.03047))
(0.40 (0.2214 0.02871))
(0.45 (0.2010 0.02682))
(0.50 (0.1798 0.02479))
(0.55 (0.1577 0.02261))
(0.60 (0.1349 0.02027))
(0.65 (0.1112 0.01777))
(0.70 (0.0867 0.01509))
(0.75 (0.0614 0.01224))
(0.80 (0.0353 0.00921))
);
}
}
\endverbatim
This update allows Zoltan to be used by snappyHexMesh to redistribute the mesh
after refinement and sub-setting even if some processors loose all their cells
in the process.
The distributions have been extended in various ways to permit usage in
a greater variety of situations...
The distributions now have write methods which allow a distribution to
be written into a field file for restart, therby permitting their usage
in boundary conditions and similar. Their read methods now also support
dimension-checked unit conversions for all their parameters.
An additional selector has been added that allows a distribution to be
re-constructed with a different sample size exponent.
The distributions now own their random generator, thereby simplifying
their usage and preventing the need for a (potentially dangling)
reference member. This makes sense now as the random generators do not
rely on global state; individual sub-models can and should own their own
random generator and manage its initialisation and restart. This
principle should be extended to other parts of the code in future.
A random generator can now be constructed with a global flag. If the
flag is false then the provided seed will be randomised across the
different processes. If the flag is true then the synchronicity of the
generators state will be checked when performing certain operations in
debug mode.
*** Note that this commit depends on a corresponding change in
ThirdParty-dev. Ensure that both repositories are up to date before
re-building OpenFOAM.
New environment variables have been added to explicitly control the
installation type of the thirdparty decomposition libraries and of the
ParaView visualiation software. These are set in the etc/bashrc and can
be overridden in a ~/.OpenFOAM/<version>/prefs.sh file or similar.
The variables relating to the decomposition libraries are SCOTCH_TYPE,
METIS_TYPE, PARMETIS_TYPE and ZOLTAN_TYPE, and they can take values of
none, system, or ThirdParty. In the case of ThirdParty, a
<library>_VERSION variable can also be specified. If the version is not
specified then the configuration will search for a source directory, and
if multiple such directories are found then the one with the highest
version number will be used.
The variable relating to ParaView is ParaView_TYPE, and this can be
similarly be set to none, system, or ThirdParty, and ParaView_VERSION
can also be specified when the type is ThirdParty. If the version is not
specified then the installation with the highest version number will be
used.
An example ~/.OpenFOAM/dev/prefs.sh file, in which all decomposition
libraries are enabled, and the Scotch and ParaView versions are
explicitly set, is as follows:
export SCOTCH_TYPE=ThirdParty
export SCOTCH_VERSION=7.0.3
export METIS_TYPE=ThirdParty
export PARMETIS_TYPE=ThirdParty
export ZOLTAN_TYPE=ThirdParty
export ParaView_TYPE=ThirdParty
export ParaView_VERSION=5.11.2
*** Note that if version numbers are not set then the configuration will
search for a decomposition source directory, but it will search for a
ParaView installation directory. This is because decomposition libraries
are built as part of OpenFOAM's ./Allwmake, but ParaView is not. This
distinction remains. If a local compilation of ParaView is needed, then
'./makeParaView -version X.XX.X' should be called explicitly in the
third party directory prior to building OpenFOAM.
The name of the third party directory can now also be independently set.
This simplifies some packaging processes in that it permits third party
to be located within the OpenFOAM installation directory and therefore
bundled into the same binary package.
With the new -rm option the processor time directories are removed after the
reconstruction of each one. For multi-region cases with the -region and -rm
options only the processor time directory for the reconstructed region is
removed whereas with the -allRegions option the entire processor time directory
is removed after reconstruction of all the regions.
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 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);
}
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.
Corrected according to the original reference:
Marschall, H. (2011).
Towards the numerical simulation of multi-scale two-phase flows.
PhD Thesis, TU München.
