to the <case>/<time>/uniform or <case>/<processor>/<time>/uniform directory.
Adding a new form of IOdictionary for this purpose allows significant
simplification and rationalisation of regIOobject::writeObject, removing the
need for explicit treatment of different file types.
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
and only needed if there is a name clash between entries in the source
specification and the set specification, e.g. "name":
{
name rotorCells;
type cellSet;
action new;
source zoneToCell;
sourceInfo
{
name cylinder;
}
}
topoSet is a more flexible and extensible replacement for setSet using standard
OpenFOAM dictionary input format rather than the limited command-line input
format developed specifically for setSet. This replacement allows for the
removal of a significant amount of code simplifying maintenance and the addition
of more topoSet sources.
With this change both
blockMesh -dict fineBlockMeshDict
blockMesh -dict system/fineBlockMeshDict
are supported, if the system/ path is not specified it is assumed
splitBaffles identifies baffle faces; i.e., faces on the mesh boundary
which share the exact same set of points as another boundary face. It
then splits the points to convert these faces into completely separate
boundary patches. This functionality was previously provided by calling
mergeOrSplitBaffles with the "-split" option.
mergeBaffles also identifes the duplicate baffle faces, but then merges
them, converting them into a single set of internal faces. This
functionality was previously provided by calling mergeOrSplitBaffles
without the "-split" option.
When using 'simple' or 'hierarchical' decomposition it is useful to slightly rotate a
coordinate-aligned block-mesh to improve the processor boundaries by avoiding
irregular cell distribution at those boundaries. The degree of slight rotation
is controlled by the 'delta' coefficient and a value of 0.001 is generally
suitable so to avoid unnecessary clutter in 'decomposeParDict' 'delta' now
defaults to this value.
The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
the previous naming tan1, tan2, normal was non-intuitive and very confusing.
It was not practical to maintain backward compatibility but all tutorials and
example refineMeshDict files have been updated to provide examples of the
change.
The inside or outside region refinement level is now specified using the simple
"level <level>" entry in refinementRegions e.g.
refinementRegions
{
refinementBox
{
mode inside;
level 5;
}
}
rather than
refinementRegions
{
refinementBox
{
mode inside;
levels ((1E15 5));
}
}
where the spurious "1E15" number is not used and the '((...))' is unnecessary clutter.
so that they operate in the conventional manner in a right-handed coordinate
system:
//- Rotational transformation tensor about the x-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rx(const scalar& omega)
//- Rotational transformation tensor about the y-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ry(const scalar& omega)
//- Rotational transformation tensor about the z-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rz(const scalar& omega)
//- Rotational transformation tensor about axis a by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ra(const vector& a, const scalar omega)
Description
Transform (translate, rotate, scale) a surface.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Supported transformations:
- \par translate=<translation vector>
Translational transformation by given vector
- \par rotate=(\<n1 vector\> \<n2 vector\>)
Rotational transformation from unit vector n1 to n2
- \par Rx=\<angle [deg] about x-axis\>
Rotational transformation by given angle about x-axis
- \par Ry=\<angle [deg] about y-axis\>
Rotational transformation by given angle about y-axis
- \par Rz=\<angle [deg] about z-axis\>
Rotational transformation by given angle about z-axis
- \par Ra=\<axis vector\> \<angle [deg] about axis\>
Rotational transformation by given angle about given axis
- \par scale=\<x-y-z scaling vector\>
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
Ry=3.485, \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
The transformation sequence is specified like a substitution string used by
Description
Transform (translate, rotate, scale) a surface.
The rollPitchYaw option takes three angles (degrees):
- roll (rotation about x) followed by
- pitch (rotation about y) followed by
- yaw (rotation about z)
The yawPitchRoll does yaw followed by pitch followed by roll.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
rollPitchYaw=(0 -3.485 0), \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
This function gives a value of one during a user-specified duration, and
zero at all other times. It is useful for defining the time range in
which an injection or ignition heat source or similar operates.
Example usage, scaling a value:
<name>
{
type scale;
scale squarePulse;
start 0;
duration 1;
value 100;
}
This function has been utilised in a number of tutorial fvOption
configurations to provide a specific window in which the fvOption is
applied. This was previously achieved by "timeStart" and "duration"
controls hard coded into the fvOptions themselves.
A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
Vertices are generated using run time compilation functionality.
File duplication avoided by placement in:
tutorials/resources/blockMesh/sloshingTank2D
tutorials/resources/blockMesh/sloshingTank3D
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
The phase-change functionality in interPhaseChangeFoam has been generalised and
moved into the run-time selectable twoPhaseChange library included into
interFoam providing optional phase-change. The three cavitation models provided
in interPhaseChangeFoam are now included in the twoPhaseChange library and the
two interPhaseChangeFoam cavitation tutorials updated for interFoam.
interPhaseChangeFoam has been replaced by a user redirection script which prints
the following message:
The interPhaseChangeFoam solver has solver has been replaced by the more general
interFoam solver, which now supports phase-change using the new twoPhaseChange
models library.
To run with with phase-change create a constant/phaseChangeProperties dictionary
containing the phase-change model specification, e.g.
phaseChangeModel SchnerrSauer;
pSat 2300; // Saturation pressure
See the following cases for an example converted from interPhaseChangeFoam:
$FOAM_TUTORIALS/multiphase/interFoam/laminar/cavitatingBullet
$FOAM_TUTORIALS/multiphase/interFoam/RAS/propeller
It is better to not select and instantiate a model, fvOption etc. than to create
it and set it inactive as the creation process requires reading of settings,
parameters, fields etc. with all the associated specification and storage
without being used. Also the incomplete implementation added a lot of
complexity in the low-level operation of models introducing a significant
maintenance overhead and development overhead for new models.
TableBase, TableFile and Table now combined into a single simpler Table class
which handle both the reading of embedded and file data using the generalised
TableReader. The new EmbeddedTableReader handles the embedded data reading
providing the functionality of the original Table class within the same
structure that can read the data from separate files.
The input format defaults to 'embedded' unless the 'file' entry is present and
the Table class is added to the run-time selection table under the name 'table'
and 'tableFile' which provides complete backward comparability. However it is
advisable to migrate cases to use the new 'table' entry and all tutorial cases
have been updated.
using Function1 and supporting all the standard Function1s including tabulated
and coded.
tutorials/multiphase/interFoam/laminar/sloshingTank3D6DoF updated to use
sixDoFMotion.
Most fvOptions change the state of the fields and equations they are applied to
but do not change internal state so it makes more sense that the interface is
const, consistent with MeshObjects. For the few fvOptions which do maintain a
changing state the member data is now mutable.
foamDictionary executions are now wrapped by runApplication like any
other execution so that they do not print during a test loop.
foamDictionary does not produce a conforming log, however, so
log.foamDictionary has been filtered out of the formation of the test
loop report so that false failures are not reported.
The new optional 'slash' scoping syntax is now the default and provides a more
intuitive and flexible syntax than the previous 'dot' syntax, corresponding to
the common directory/file access syntax used in UNIX, providing support for
reading entries from other dictionary files.
In the 'slash' syntax
'/' is the scope operator
'../' is the parent dictionary scope operator
'!' is the top-level dictionary scope operator
Examples:
internalField 3.4;
active
{
type fixedValue;
value.air $internalField;
}
inactive
{
type anotherFixedValue;
value $../active/value.air;
anotherValue $!active/value.air;
sub
{
value $../../active/value.air;
anotherValue $!active/value.air;
}
}
"U.*"
{
solver GAMG;
}
e.air
{
$U.air;
}
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
If there is a part of the keyword before the '!' then this is taken to be the
file name of the dictionary from which the entry will be looked-up using the
part of the keyword after the '!'. For example given a file testSlashDict containing
internalField 5.6;
active
{
type fixedValue;
value.air $internalField;
}
entries from it can be read directly from another file, e.g.
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
which expands to
external
{
value 5.6;
}
active2
{
type fixedValue;
value.air 5.6;
}
These examples are provided in applications/test/dictionary.
The the default syntax can be changed from 'slash' to 'dot' in etc/controlDict
to revert to the previous behaviour:
OptimisationSwitches
{
.
.
.
// Default dictionary scoping syntax
inputSyntax slash; // Change to dot for previous behaviour
}
or within a specific dictionary by adding the entry
See applications/test/dictionary/testDotDict.
A new family of interface compression interpolation schemes based on
piecewise-linear interface calculation (PLIC). PLIC represents an interface by
surface-cuts which split each cell to match the volume fraction of the phase in
that cell. The surface-cuts are oriented according to the point field of the
local phase fraction. The phase fraction on each cell face — the interpolated
value — is then calculated from the amount submerged below the surface-cut.
The basic PLIC method generates a single cut so cannot handle cells in which
there are multiple interfaces or where the interface is not fully resolved. In
those cells, the interpolation reverts to an alternative scheme, typically
standard interface compression. PLIC, with a fallback to interface compression,
produces robust solutions for real engineering cases. It can run with large time
steps so can solve problems like hydrodynamics of a planing hull, with rigid
body motion of the hull (above). The user selects PLIC by the following setting
in fvSchemes:
div(phi,alpha) Gauss PLIC interfaceCompression vanLeer 1;
The multicut PLIC (MPLIC) scheme extends PLIC to handle multiple
surface-cuts. Where a single cut is insufficient, MPLIC performs a topological
face-edge-face walk to produce multiple splits of a cell. If that is still
insufficient, MPLIC decomposes the cell into tetrahedrons on which the cuts are
applied. The extra cutting carries an additional computational cost but requires
no fallback. The user selects MPLIC by the following setting in the fvSchemes
file:
div(phi,alpha) Gauss MPLIC;
Variants of the PLIC and MPLIC schemes are also available which use velocities
at the face points to calculate the face flux. These PLICU and MPLICU schemes
are likely to be more accurate in regions of interface under high shear.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Jakub Knir
CFD Direct Ltd.
A new run-time selectable interface compression scheme framework has been added
to the two-phase VoF solvers to provide greater flexibility, extensibility and
more consistent user-interface. The previously built-in interface compression
is now in the standard run-time selectable surfaceInterpolationScheme
interfaceCompression:
Class
Foam::interfaceCompression
Description
Interface compression corrected scheme, based on counter-gradient
transport, to maintain sharp interfaces during VoF simulations.
The interface compression is applied to the face interpolated field from a
suitable 2nd-order shape-preserving NVD or TVD scheme, e.g. vanLeer or
vanAlbada. A coefficient is supplied to control the degree of compression,
with a value of 1 suitable for most VoF cases to ensure interface integrity.
A value larger than 1 can be used but the additional compression can bias
the interface to follow the mesh more closely while a value smaller than 1
can lead to interface smearing.
Example:
\verbatim
divSchemes
{
.
.
div(phi,alpha) Gauss interfaceCompression vanLeer 1;
.
.
}
\endverbatim
The separate scheme for the interface compression term "div(phirb,alpha)" is no
longer required or used nor is the compression coefficient cAlpha in fvSolution
as this is now part of the "div(phi,alpha)" scheme specification as shown above.
Backward-compatibility is provided by checking the specified "div(phi,alpha)"
scheme against the known interface compression schemes and if it is not one of
those the new interfaceCompression scheme is used with the cAlpha value
specified in fvSolution.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Henry G. Weller
CFD Direct Ltd.
