The reactingtTwoPhaseEulerFoam solver has been replaced by the more general
multiphaseEulerFoam solver which supports two-phase and multiphase systems
containing fluid and stationary phases, compressible or incompressible, with
heat and mass transfer, reactions, size distribution and all the usual phase
interaction and transfer models.
All reactingtTwoPhaseEulerFoam tutorials have been ported to multiphaseEulerFoam
to demonstrate two-phase capability with a wide range of phase and
phase-interaction models.
When running with two-phases the optional referencePhase entry in
phaseProperties can be used to specify which phase fraction should not be
solved, providing compatibility with reactingtTwoPhaseEulerFoam, see
tutorials/multiphase/multiphaseEulerFoam/RAS/fluidisedBed
tutorials/multiphase/multiphaseEulerFoam/laminar/bubbleColumn
for examples.
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.
The base phaseSystem now provides all the functionality needed for
reactingMultiphaseEulerFoam and twoPhaseSystem is a specialisation, simplifying
maintenance.
Description
This functionObject writes the phase-fraction map field alpha.map with
incremental value ranges for each phase
e.g., with values 0-1 for water, 1-2 for air, 2-3 for oil etc.
Example of function object specification:
\verbatim
phaseMap
{
type phaseMap;
libs ("libreactingEulerFoamFunctionObjects.so");
writeControl writeTime;
}
\endverbatim
Usage
\table
Property | Description | Required | Default value
type | type name: phaseMap | yes |
\endtable
This replaces the alphas functionality previously built-in to
reactingMultiphaseEulerFoam so that the storage, calculation and writing of the
phase map field is now under user control.
The optional reference phase fraction field is not read even if the file is
present, it is constructed with "calculated" BCs as it is a derived field. All
other phase fraction field files are read and now must be present.
for compatibility with reactingMultiphaseEulerFoam when run with two-phases.
Some of these two-phase models could be enhanced to operate with multiple
dispersed phases in the future.
In order to update these models for reactingMultiphaseEulerFoam it has been
necessary to break compatibility with the now redundant twoPhaseEulerFoam solver
which has been superseded by the much more capable reactingEulerFoam solvers and
now removed.
to ensure the velocity and flux of the phases sum the conservative mixture
values obtained from the pressure solution.
Also corrected handling of MRF and updated to work with partial elimination.
Added optional pressure reference pRef to p_rgh in buoyantPimpleFoam,
buoyantSimpleFoam and chtMultiRegionFoam which handles cases in which the
pressure variation is small compared to the pressure level more accurately.
The pRef value is provided in the optional constant/pRef file.
All tutorials and templates have been updated to use pRef as appropriate.
This change protects the lookup of the drag model so that if it is not
found then the drag terms in the Theta equation are set to zero. This is
not likely to be correct usage in physical cases, but is useful for
doing uncoupled simulations for the purpose of model verification.
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.
The solid is currently assumed incompressible (the solid pressure is not
updated) and in general would be near incompressible so internal energy is a
more appropriate energy choice than enthalpy which would require a pressure work
term currently not implemented. Additionally due to the way in which the
conduction is handled in terms of the gradient of energy the accuracy of the
current enthalpy implementation is sensitive to the pressure distribution as
this introduces an enthalpy gradient from the p/rho term which would need to be
corrected; this issue is avoided by solving for internal energy instead.
This improvement requires the scheme and solver settings for the solids in
chtMultiRegionFoam cases to be changed from "h" to "e" and the thermo-physical
properties in <solid>/thermophysicalProperties to be set to the corresponding
internal energy forms, e.g.:
thermo eConst;
.
.
.
energy sensibleInternalEnergy;
All tutorials have be updated to reflect this and provide guidance when updating
cases.
foamDictionary operates on individual dictionary files irrespective of their
location or case they may be associated with and hence a case database is not
needed to read them.
using the new nonUniformTable to interpolate between the values vs temperature
provided. All properties (density, heat capacity, viscosity and thermal
conductivite) are considered functions of temperature only and the equation of
state is thus incompressible. Built-in mixing rules corresponding to those in
the other thermo and transport models are not efficient or practical for
tabulated data and so these models are currently only instantiated for the pure
specie/mixture rhoThermo package but a general external mixing method will be
added in the future.
To handle reactions the Jacobian function dKcdTbyKc has been rewritten to use
the Gstd and S functions directly removing the need for the miss-named dGdT
function and hence removing the bugs in the implementation of that function for
some of the thermo models. Additionally the Hc() function has been renamed
Hf() (heat of formation) which is more commonly used terminology and consistent
with the internals of the thermo models.
All models that require templating on the thermodynamic model, including
the thermodynamic models themselves, are now instantiated using a
centralised set of variadic macros. Seven macros exist to instantiate
models for different classes of thermodynamics model. These are:
forGases: All model combinations valid for gases
forCommonGases: The most commonly used gas models
forAbsoluteGases: A limited selection of gas models with absolute
forms of energy, for use with Xi-combustion models
forLiquids: All model combinations valid for liquids
forCommonLiquids: The most commonly used liquid models
forPolynomials: Model combinations with properties fitted to
polynomials
forSolids: All model combinations valid for solids
All the *ThermoPhysics typedefs have been removed, as this system was
fundamentally not extensible. The enormous lists of thermodynamic
instantiations that existed for reaction thermos, chemistry models,
tabulation methods, etc..., were extremely difficult to read and reason
about what combinations are valid under what circumstances. This change
centralises those decisions, makes them concise and readable, and makes
them consistent across the entire codebase.
Soot model selection has now been brought up to date in line with
chemistry, combustion, and others. The angle-bracketed part of the name
is no longer necessary; this information is determined directly from the
existing thermo model. So, now to select a mixture-fraction soot model,
the entry is simply:
sootModel mixtureFraction;
Rather than:
sootModel mixtureFraction<rhoReactionThermo,gasHThermoPhysics>;
The only place in which *ThermoPhysics typedefs are still required in
the selection name is in the thermalBaffle1D boundary condition. Here
there is no thermo model from which to determine a name. This eventually
needs resolving either by adding a selection mechanism similar to that
of the thermo packages themselves, or by removing this boundary
condition in favour of the (non-1D) thermal baffle boundary condition
and region model.
Description
Non-uniform tabulated property function that linearly interpolates between
the values.
To speed-up the search of the non-uniform table a uniform jump-table is
created on construction which is used for fast indirect addressing into
the table.
Usage
\nonUniformTable
Property | Description
values | List of (temperature property) value pairs
\endnonUniformTable
Example for the density of water between 280 and 350K
\verbatim
rho
{
type nonUniformTable;
values
(
(280 999.87)
(300 995.1)
(350 973.7)
);
}
\endverbatim
This allows specification of a turbulent Schmidt number independent from
that of the turbulent Prandtl number. An example specification in
constant/thermophysicalTransport is as follows:
RAS
{
model nonUnityLewisEddyDiffusivity;
Prt 0.85;
Sct 0.7;
}
The defaulting of the turbulent Prandtl number (Prt) to 1 has also been
removed from the eddyDiffusivity model. Now the value must be set
explicitly. The only exception is if the
constant/thermophysicalTransport dictionary is omitted entirely, in
which case eddyDiffusivity with a turbulent Prandtl number of 1 is
selected as before.
Now the PhaseThermophysicalTransportModel in reactingEulerFoam has access to
either rhoThermo or rhoReactionThermo depending on the choice of the thermo
package and provides necessary to structure to support multi-component diffusion
for reacting phases in the future.
Updated reacting solvers to use psiReactionThermophysicalTransportModel or
rhoReactionThermophysicalTransportModel as appropriate to provide support for
interacting heat and specie transport.
ThermophysicalTransportModel is now instantiated on both the
MomentmumTransportModel and also the particular thermo model model rather than
obtaining the fluidThermo from the MomentmumTransportModel. This gives direct
access to the higher-level thermo model used in the solver, for example
rhoReactionThermo so that complex ThermophysicalTransportModels requiring access
to the composition for example are instantiated only for thermo models that
provide it and also avoiding run-time up-casting of the thermo model.
