Now that the reaction system, chemistry and combustion models are completely
separate from the multicomponent mixture thermophysical properties package that
supports them it is inconsistent that thermo is named reactionThermo and the
name multicomponentThermo better describes the purpose and functionality.
To simplify maintenance and further development of chemistry solution the
standardChemistryModel and TDACChemistryModel have been merged into the single
chemistryModel class. Now the TDAC mechanism reduction and tabulation
components can be individually selected or set to "none" or the corresponding
entries in the chemistryProperties dictionary omitted to switch them off thus
reproducing the behaviour of the standardChemistryModel.
For example the following chemistryProperties includes TDAC:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
tolerance 1e-4;
}
tabulation
{
tolerance 3e-3;
}
#include "reactionsGRI"
and to run without TDAC the following is sufficient:
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
#include "reactionsGRI"
or the "reduction" and "tabulation" entries can be disabled explicitly:
#includeEtc "caseDicts/solvers/chemistry/TDAC/chemistryProperties.cfg"
chemistryType
{
solver ode;
}
chemistry on;
initialChemicalTimeStep 1e-7;
odeCoeffs
{
solver seulex;
absTol 1e-8;
relTol 1e-1;
}
reduction
{
method none;
tolerance 1e-4;
}
tabulation
{
method none;
tolerance 3e-3;
}
#include "reactionsGRI"
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.
