MRF (multiple reference frames) can now be used to simulate SRF (single
reference frame) cases by defining the MRF zone to include all the cells is the
mesh and applying appropriate boundary conditions. The huge advantage of this
is that MRF can easily be added to any solver by the addition of forcing terms
in the momentum equation and absolute velocity to relative flux conversions in
the formulation of the pressure equation rather than having to reformulate the
momentum and pressure system based on the relative velocity as in traditional
SRF. Also most of the OpenFOAM solver applications and all the solver modules
already support MRF.
To enable this generalisation of MRF the transformations necessary on the
velocity boundary conditions in the MRF zone can no longer be handled by the
MRFZone class itself but special adapted fvPatchFields are required. Although
this adds to the case setup it provides much greater flexibility and now complex
inlet/outlet conditions can be applied within the MRF zone, necessary for some
SRF case and which was not possible in the original MRF implementation. Now for
walls rotating within the MRF zone the new 'MRFnoSlip' velocity boundary
conditions must be applied, e.g. in the
tutorials/modules/incompressibleFluid/mixerVessel2DMRF/constant/MRFProperties
case:
boundaryField
{
rotor
{
type MRFnoSlip;
}
stator
{
type noSlip;
}
front
{
type empty;
}
back
{
type empty;
}
}
similarly for SRF cases, e.g. in the
tutorials/modules/incompressibleFluid/mixerSRF case:
boundaryField
{
inlet
{
type fixedValue;
value uniform (0 0 -10);
}
outlet
{
type pressureInletOutletVelocity;
value $internalField;
}
rotor
{
type MRFnoSlip;
}
outerWall
{
type noSlip;
}
cyclic_half0
{
type cyclic;
}
cyclic_half1
{
type cyclic;
}
}
For SRF case all the cells should be selected in the MRFproperties dictionary
which is achieved by simply setting the optional 'selectionMode' entry to all,
e.g.:
SRF
{
selectionMode all;
origin (0 0 0);
axis (0 0 1);
rpm 1000;
}
In the above the rotational speed is set in RPM rather than rad/s simply by
setting the 'rpm' entry rather than 'omega'.
The tutorials/modules/incompressibleFluid/rotor2DSRF case is more complex and
demonstrates a transient SRF simulation of a rotor requiring the free-stream
velocity to rotate around the apparently stationary rotor which is achieved
using the new 'MRFFreestreamVelocity' velocity boundary condition. The
equivalent simulation can be achieved by simply rotating the entire mesh and
keeping the free-stream flow stationary and this is demonstrated in the
tutorials/modules/incompressibleFluid/rotor2DRotating case for comparison.
The special SRFSimpleFoam and SRFPimpleFoam solvers are now redundant and have
been replaced by redirection scripts providing details of the case migration
process.
This required changing the formulation of the relative velocity in terms of a
scalar velocity coefficient Vc rather than the velocity V0 such that
V0 = Vc*g
where g is the acceleration due to gravity. With MRF rotation
V0 = Vc*(g + <MRF centrifugal acceleration>)
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.
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.
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.
Following the generalisation of the TurbulenceModels library to support
non-Newtonian laminar flow including visco-elasticity and extensible to other
form of non-Newtonian behaviour the name TurbulenceModels is misleading and does
not properly represent how general the OpenFOAM solvers now are. The
TurbulenceModels now provides an interface to momentum transport modelling in
general and the plan is to rename it MomentumTransportModels and in preparation
for this the turbulenceProperties dictionary has been renamed momentumTransport
to properly reflect its new more general purpose.
The old turbulenceProperties name is supported for backward-compatibility.
renaming the legacy keywords
RASModel -> model
LESModel -> model
laminarModel -> model
which is simpler and clear within the context in which they are specified, e.g.
RAS
{
model kOmegaSST;
turbulence on;
printCoeffs on;
}
rather than
RAS
{
RASModel kOmegaSST;
turbulence on;
printCoeffs on;
}
The old keywords are supported for backward compatibility.
This provides more flexibility in specifying the allowed internal and boundary
extrema.
For driftFluxFoam and other settling problems it is beneficial to set the
boundaryExtremaCoeff to 1 to allow rapid accumulation of the partials on the
bottom wall (which was the previous default behaviour) but this is not suitable
for many Euler-Euler cases for which a uniform etrema coefficient is preferable,
either 0 or a small value.
Now by default boundaryExtremaCoeff is set to extremaCoeff which defaults to 0
which provides the behaviour before
OpenFOAM-dev commit cb2bc60fa5
and the driftFluxFoam tutorials have been updated adding
boundaryExtremaCoeff 1;
to the MULES controls in fvSolution so reproduce the previous behaviour.
Using the noSlip boundary condition for rotating wall in an MRF region
interferes with post-processing by resetting the wall velocity to 0 rather than
preserving the value set by the MRF zone.
