An additional layer has been added into the phase system hierarchy which
facilitates the application of phase transfer modelling. These are
models which exchange mass between phases without the thermal coupling
that would be required to represent phase change. They can be thought of
as representation changes; e.g., between two phases representing
different droplet sizes of the same physical fluid.
To facilitate this, the heat transfer phase systems have been modified
and renamed and now both support mass transfer. The two sided version
is only required for derivations which support phase change.
The following changes to case settings have been made:
- The simplest instantiated phase systems have been renamed to
basicTwoPhaseSystem and basicMultiphaseSystem. The
heatAndMomentumTransfer*System entries in constant/phaseProperties files
will need updating accordingly.
- A phaseTransfer sub-model entry will be required in the
constant/phaseProperties file. This can be an empty list.
- The massTransfer switch in thermal phase change cases has been renamed
phaseTransfer, so as not to be confused with the mass transfer models
used by interface composition cases.
This work was supported by Georg Skillas and Zhen Li, at Evonik
Sub-model blending should be set such that the sum of all the blending
coefficients equals one. If there are three models specified for a phase
pair (e.g., (air in water), (water in air) and (air and water)), then
the sum-to-one constraint is guaranteed by the blending functions.
Frequently, however, the symmetric model ((air and water) in this
example) is omitted. In that case, the blending coefficients should be
selected so that the sum of just the two non-symmetric coefficients
equal one.
In the case of linear blending, this means setting the minimum partially
continuous alpha to one-minus the fully continuous value of the opposite
phase. For example:
blending
{
default
{
type linear;
minFullyContinuousAlpha.air 0.7;
minPartlyContinuousAlpha.air 0.3;
minFullyContinuousAlpha.water 0.7;
minPartlyContinuousAlpha.water 0.3;
}
}
The reactingTwoPhaseEulerFoam and reactingMultiPhaseEulerFoam tutorials
have been modified to adhere to this principle.
Partial elimination has been implemented for the multiphase Euler-Euler
solver. This does a linear solution of the drag system when calculating
flux and velocity corrections after the solution of the pressure
equation. This can improve the behaviour of the solution in the event
that the drag coupling is high. It is controlled by means of a
"partialElimination" switch within the PIMPLE control dictionary in
fvSolution.
A re-organisation has also been done in order to remove the exposure of
the sub-modelling from the top-level solver. Rather than looping the
drag, virtual mass, lift, etc..., models directly, the solver now calls
a set of phase-system methods which group the different force terms.
These new methods are documented in MomentumTransferPhaseSystem.H. Many
other accessors have been removed as a consequence of this grouping.
A bug was also fixed whereby the face-based algorithm was not
transferring the momentum associated with a given interfacial mass
transfer.
Some tutorials have had Allrun scripts added in order to run setFields,
which was previously omitted. Others have had nonuniform field files in
the 0 directory replaced by uniform files with .orig extensions.
Now if a <field> file does not exist first the compressed <field>.gz file is
searched for and if that also does not exist the <field>.orig file is searched
for.
This simplifies case setup and run scripts as now setField for example can read
the <field>.orig file directly and generate the <field> file from it which is
then read by the solver. Additionally the cleanCase function used by
foamCleanCase and the Allclean scripts automatically removed <field> files if
there is a corresponding <field>.orig file. So now there is no need for the
Allrun scripts to copy <field>.orig files into <field> or for the Allclean
scripts to explicitly remove them.
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass. This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties. In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties. This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based. Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.
This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.
Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing
nMoles 1;
entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet. The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions. This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO
// Reactants (mole-based)
thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
// Oxidant (mole-based)
thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
// Intermediates (mole-based)
thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
// Products (mole-based)
thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
thermo CO(thermoData.subDict("CO")); CO *= CO.W();
// Product dissociation reactions
thermo CO2BreakUp
(
CO2 == CO + 0.5*O2
);
thermo H2OBreakUp
(
H2O == H2 + 0.5*O2
);
Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org
Henry G. Weller
CFD Direct Ltd.
See http://www.openfoam.org/mantisbt/view.php?id=2076
- .org is the file extension for emacs org-mode as well
- .orig is more to the point (.org isn't always recognized as "original")
- .original is too long, although more consistent with the convention
of source code file naming
Update script contributed by Bruno Santos
so that the specification of the name and dimensions are optional in property dictionaries.
Update tutorials so that the name of the dimensionedScalar property is
no longer duplicated but optional dimensions are still provided and are
checked on read.
Multi-species, mass-transfer and reaction support and multi-phase
structure provided by William Bainbridge.
Integration of the latest p-U and face-p_U algorithms with William's
multi-phase structure is not quite complete due to design
incompatibilities which needs further development. However the
integration of the functionality is complete.
The results of the tutorials are not exactly the same for the
twoPhaseEulerFoam and reactingTwoPhaseEulerFoam solvers but are very
similar. Further analysis in needed to ensure these differences are
physical or to resolve them; in the meantime the twoPhaseEulerFoam
solver will be maintained.
