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.
for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of chemistry model and solver selected in chemistryProperties
is not already compiled and present in the standard libraries for the selected
thermophysical properties the chemistry package will be constructed and compiled
automatically using the standard dynamicCode system provided in OpenFOAM.
The chemistry package is constructed automatically from the
etc/codeTemplates/dynamicCode/basicChemistryModel.* files, if these files do not
exist the standard chemistry lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the chemistry package is only
enabled if allowSystemOperations is set true.
for chemFoam, fireFoam, buoyantReactingFoam, reactingFoam, chtMultiRegionFoam,
buoyantReactingParticleFoam, reactingParticleFoam, simpleReactingParticleFoam
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo type,
fluidThermo, fluidReactionThermo etc. If the corresponding codeTemplates files
do not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
If the combination of property models selected in thermophysicalProperties is
not already compiled and present in the standard libraries the thermophysical
property package will be constructed and compiled automatically using the
standard dynamicCode system provided in OpenFOAM.
The thermophysical property package is constructed automatically from the
etc/codeTemplates/dynamicCode files for the corresponding base thermo
type (e.g. fluidThermo), currently these are provided only for fluidThermo but
the others will be added shortly. If the corresponding codeTemplates files do
not exist the standard thermo lookup error message is generated as before.
As with all other dynamicCode options in OpenFOAM (codeStream,
codedFunctionObject etc.) dynamic compilation of the thermophysical property
package is only enabled if allowSystemOperations is set true.
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.
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.
There are now three possible code entries for the scalarCodedSource,
vectorCodedSource, etc..., fvOptions. These are `codeAddSup` for basic
sources, `codeAddRhoSup` for compressible sources, and
`codeAddAlphaRhoSup` for phase (compressible) sources.
Previously `codeAddSup` was used for both basic and compressible
sources, and phase sources were not implemented. This meant that whilst
a compressible source could be created, it could not make use of the
`rho` argument or the basic source function would fail to compile.
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.
For example in the new tutorial case:
tutorials/incompressible/pimpleFoam/laminar/pitzDailyPulse
a cosine bell velocity pulse is specified at the inlet by directly defining the
code for it:
inlet
{
type uniformFixedValue;
uniformValue coded;
name pulse;
codeInclude
#{
#include "mathematicalConstants.H"
#};
code
#{
return vector
(
0.5*(1 - cos(constant::mathematical::twoPi*min(x/0.3, 1))),
0,
0
);
#};
}
which is then compiled automatically and linked into the running pimpleFoam
dynamically and executed to set the inlet velocity.
Currently these deleted function declarations are still in the private section
of the class declarations but will be moved by hand to the public section over
time as this is too complex to automate reliably.
The writeEntry form is now defined and used consistently throughout OpenFOAM
making it easier to use and extend, particularly to support binary IO of complex
dictionary entries.
The dynamic code functionality has been generalised so that the names of
the code entries in the specifying dictionary can be set by the caller.
This means that functions which utilise dynamic code but use different
entry names (e.g., codedFunctionObject uses codeExecute, codeEnd,
etc..., instead of code) now function correctly. The differently named
entries now form part of the library hash, and re-building triggers
appropriately as they are modified.
The construction of some patch fields has been corrected so that the
patchType setting always propagates on mapping, IO, clone, etc...
Dictionary and mapping-based patch field constructors now call the
corresponding constructor from the base class, regardless of whether
dictionary settings or mapping are actually needed.
A "mappingRequired" flag has been added to some of the base constructors
in order to prevent unecessary mapping of field data and retain the
previous level of optimisation.
Resolves bug report https://bugs.openfoam.org/view.php?id=3144
