A new class, phaseInterface, has been added to represent interfacial
configurations between pairs of phases. This class and its derivations
explicitly represent different configurations (e.g., dispersal,
segregation, displacement) by type and provide a run-time selection
mechanism so that these configurations can be uniquely named and
intuitively selected for sub-models to apply to.
For example, drag models can be selected for an air-water system with
full phase inversion with the following syntax in
constant/phaseProperties:
drag
{
air_dispersedIn_water
{
type IshiiZuber;
}
air_segregatedWith_water
{
type segregated;
m 0.5;
n 8;
}
steam_dispersedIn_water
{
type SchillerNaumann;
residualRe 1e-3;
}
}
As well as the entries now being underscore separated, note also that
the sub model sections are now dictionaries ("{ ... }"), rather than
lists ("( ... );"). If a list is provided instead, then the input will
be considered to be in the old syntax, and will be read in a backwards
compatibility mode.
The new dictionary syntax permits substitution and therefore reuse of
settings, reducing the workload associated with setting up a large case
with many model combinations. In future it may be possible to introduce
wildcards to further reduce the verbosity of the input.
The new phase-interface classes and keywords and the phase-pairs and
keywords that they replace are listed below:
Default/General: phaseInterface "<phase>_<phase>"
replaces phasePair "(<phase> and <phase>)"
Dispersed: dispersedPhaseInterface "<phase>_dispersedIn_<phase>"
replaces orderedPhasePair "(<phase> in <phase>)"
Segregated: segregatedPhaseInterface "<phase>_segregatedWith_<phase>"
replaces phasePair "(<phase> and <phase>)"
Sided: sidedPhaseInterface "<phase>_<phase>_inThe_<phase>"
replaces orderedPhasePair "(<phase> in <phase>)"
Displaced: displacedPhaseInterface "<phase>_<phase>_displacedBy_<phase>"
is new
Interface combinations are also possible. There can be, for example, an
interface which is both dispersed and sided. This class is the
dispersedSidedPhaseInterface and can be selected with the keyword
"<phase>_dispersedIn_<phase>_inThe_<phase>". This is needed, for
example, in two-resistance heat transfer modelling, where a different
model can be selected to represent heat transfer within the fluids on
either side of an interface.
A full list of all available phase interface relationships can be
generated by specifying an incorrect name, and viewing the output of the
error message that results.
The "displaced" interface is not currently used, but will shortly be
utilised to allowing the user to control how models between phases
change as the fraction of a third phase becomes significant and
displaces the phases associated with the interface in question.
Notes for developers:
There is no centralised storage of phase interface relationships in the
phase system any more; the table of phasePairs has been removed, and
there is no correcponding table of phaseInterfaces. Models now locally
store their own phaseInterface objects, or a derivation thereof, rather
than a reference to a centrally stored object. These phaseInterface
classes hold only references so there is no cost associated with their
duplication in multiple sub models.
If a model requires an interface of a specific type, it has to down-cast
the interface provided to it. There is a `phaseSystem::modelCast` method
for this purpose which also provides meaningful error messages in the
event that an inappropriate interface was specified and the cast fails.
Model generation is now hierarchical. Wrapper models (blended and sided)
are constructed with the same interface as non-wrapper models (drag,
virtual mass, etc...). The wrapper model constructors call the
constructors of their sub-models directly, rather than requiring model
pointers to be passed in.
Sub-model lookup has been significantly generalised and simplified.
There is now just one `phaseSystem::lookupInterfacialModel` method which
takes a phaseInterface as its argument. Looking up a model for a
specific configuration just requires providing the appropriate
phaseInterface. E.g., this call will return the virtual mass model for
gas bubbles in liquid:
lookupSubModel<virtualMassModel>(dispersedPhaseInterface(gas, liquid))
Whilst this call will return the drag model for the segregated regime:
lookupSubModel<dragModel>(segregatedPhaseInterface(phase1, phase2))
And this call will return the complete blended heat transfer model:
lookupSubModel<blendedHeatTransferModel>(phaseInterface(phase1, phase2))
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.
