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.
All heat transfers that result from mass-transfer are now implemented in
terms of sensible enthalpy, so that they are consistent regardless of
which form of energy is being solved for. This has removed some spurious
temperature anomalies from a number of cases involving mass-transfer.
All heat transfers that result from mass-transfer are now linearised. In
the case of multi-specie systems this requires the specification of a
residual mass fraction, which is given by a new "residualY" keyword in
the constant/phaseProperties dictionary. If this entry is omitted for
multi-specie systems then linearisation is deactivated.
**** Details for developers ****
Methods have been added to the base heat transfer phase systems to
permit energy transfer as a result of phase change, without coupling to
a diffusive heat transfer model. These functions require a "weight" to
be specified in the call to define how the latent heat is divided
between either side of the interface. A weight of 0 indicates that the
latent heat is dissipated entirely in the upwind phase, and 1 means it
is entirely in the downwind phase.
The forms of latent heat calculation and transfer have been standardised
between the various phase systems. There are now two methods of
calculating the latent heat, and two methods of applying the transfer
(see below for details). These options are currently hard-coded into the
systems that use them, but they could be made user modifiable
per-mass-transfer in future.
Interface temperatures are now stored by the derived phase systems
alongside their corresponding mass transfer rates. These temperatures
are passed by argument to the phase-change heat transfer methods
provided by the base heat transfer systems. This allows multiple
mechanisms of mass transfer each involving different interface state to
occur across the same interface.
These changes have allowed all phase systems to use the same set of
base energy-transfer functionality.
**** Even more details for developers ****
The two forms of latent heat scheme available are:
symmetric: The latent heat is calculated as the difference between
the interface enthalpies on either side of an interface.
This is the simplest form.
upwind: The latent heat is calculated as the difference between
the bulk enthalpy on the side of the interface that mass
is being transferred from and the interface enthalpy on
the side of the interface that mass is transferring to.
This form may confer some stability benefits.
The two format of latent heat transfer are:
heat: The latent heat is applied by transferring heat unequally
on either side of an interface using the difference
between the bulk phase temperatures and the interface
temperature. No explicit latent heat source is required.
This method has a stability advantage over the "mass"
option, but the transfer is not energy conservative
unless the interface temperature is exactly correct.
mass: The latent heat is applied as an explicit mass transfer
source to both sides of an interface. The ratio between
the heat transfer coefficients on either side determines
what proportion of the latent heat source ends up in each
phase. Heat transfer is calculated equally on both sides
of an interface using bulk phase temperatures and is not
coupled to the thermal effect of phase change. This
method has the advantage of being energy conservative
even if the interface temperature is not exact, but it is
less stable than the "heat" option at extreme conditions.
alphah is derived from kappa/Cp and mixing rules should be applied to kappa and
Cp separately rather than to alphah so it is more consistent to calculate the
mixture alphah from the mixture kappa and Cp at the heThermo level.
The new multiphaseEulerFoam is based on reactingMultiphaseEulerFoam with some
improvements and rationalisation to assist maintenance and further development.
The phase system solution has been enhanced to handle two phases more
effectively and all two-phase specific models updated for compatibility so that
multiphaseEulerFoam can also replace reactingTwoPhaseEulerFoam.
When running multiphaseEulerFoam with only two-phases the default behaviour is
to solve for both phase-fractions but optionally a reference phase can be
specified so that only the other phase-fraction is solved, providing better
compatibility with the behaviour of reactingTwoPhaseEulerFoam.
All reactingMultiphaseEulerFoam and reactingTwoPhaseEulerFoam tutorials have
been updated for multiphaseEulerFoam.
