and renamed defaultSpecie as its mass fraction is derived from the sum of the
mass fractions of all other species and it need not be inert but must be present
everywhere, e.g. N2 in air/fuel combustion which can be involved in the
production of NOx.
The previous name inertSpecie in thermophysicalProperties is supported for
backward compatibility.
and changed to be an energy implicit correction to a temperature gradient
based heat-flux. This formulation is both energy conservative and temperature
consistent.
The wallHeatFlux functionObject has been updated to use a consistent heat-flux
from the heSolidThermo.
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.
Expanded the documentation and updated the mean free path calculation
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
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.
Optional switches "splitPhaseFlux" and "meanFluxReference" are now provided and
can be set true in fvSolution e.g.
solvers
{
"alpha.*"
{
nAlphaCorr 1;
nAlphaSubCycles 2;
splitPhaseFlux true;
meanFluxReference true;
}
.
.
.
to reinstate the previous form of phase flux limiters in which the mean and
phase flux differences are interpolated separately and the limited correction
referenced to the mean rather than phase flux. This form of discretisation and
limiting is more aggressive than the latest version and hence less accurate but
it is hoped that the latest form of limitSum will handle the boundedness at the
upper limit reliably allowing the new more accurate limiters to be used for most
if not all multiphase simulations.
limitSum operates on the sum positive and negative flux corrections as it did
originally to guarantee that the phase fractions sum to 1 but now on the scaled
moving sub-set of the phases so that it handles the presence of stationary
phases in a consistent manner.
Additionally limitSum is now applied to two-phase systems even when only one of
the phases is solved for to ensure the solution is the same irrespective of
which phase fraction is solved or if both are solved.
compressibleMultiphaseInterFoam and multiphaseInterFoam have been updated to use
the same form of limitSum as multiphaseInterFoam but this does not change their
behaviour, it is to reduce code duplication.
psiReactionThermo- and rhoReactionThermo-s now derive from an additional
fluidReactionThermo class and are included on a corresponding run-time
selection table.
This means all multi-specie solvers can now be used with either
compressibility/psi- or density/rho-based thermodynamic models, in the
same way that non-reacting solvers can.
rhoReactingFoam has been removed, as it is no longer necessary now that
reactingFoam can operate with density-based thermodynamics.
rhoReactingBuoyantFoam has also been renamed buoyantReactingFoam to
reflect the fact that it is no longer a variant specific to
density-based thermodynamics; it can now operate with
compressibility-based thermodynamic models as well.
The change is fully backwards compatible. All cases should continue to
run without modification, apart from the fact that a different solver
might need to be called.
Most fvOptions change the state of the fields and equations they are applied to
but do not change internal state so it makes more sense that the interface is
const, consistent with MeshObjects. For the few fvOptions which do maintain a
changing state the member data is now mutable.
Now cellSetOption correctly handles the update of the cell set following mesh
topology changes rather than every time any of the fvOption functions are
called for moving meshes. This is more efficient and consistent with the rest
of OpenFOAM and avoids a lot of unnecessary clutter in the log.
This is useful for testing purposes in comparison with rhoPimpleFoam.
Also made a fix to the handling of multivariate convection schemes in
chtMultiRegionFoam.
The standard set of Lagrangian clouds are now selectable at run-time.
This means that a solver that supports Lagrangian modelling can now use
any type of cloud (with some restrictions). Previously, solvers were
hard-coded to use specific cloud modelling. In addition, a cloud-list
structure has been added so that solvers may select multiple clouds,
rather than just one.
The new system is controlled as follows:
- If only a single cloud is required, then the settings for the
Lagrangian modelling should be placed in a constant/cloudProperties
file.
- If multiple clouds are required, then a constant/clouds file should be
created containing a list of cloud names defined by the user. Each
named cloud then reads settings from a corresponding
constant/<cloudName>Properties file. Clouds are evolved sequentially
in the order in which they are listed in the constant/clouds file.
- If no clouds are required, then the constant/cloudProperties file and
constant/clouds file should be omitted.
The constant/cloudProperties or constant/<cloudName>Properties files are
the same as previous cloud properties files; e.g.,
constant/kinematicCloudProperties or constant/reactingCloud1Properties,
except that they now also require an additional top-level "type" entry
to select which type of cloud is to be used. The available options for
this entry are:
type cloud; // A basic cloud of solid
// particles. Includes forces,
// patch interaction, injection,
// dispersion and stochastic
// collisions. Same as the cloud
// previously used by
// rhoParticleFoam
// (uncoupledKinematicParticleFoam)
type collidingCloud; // As "cloud" but with resolved
// collision modelling. Same as the
// cloud previously used by DPMFoam
// and particleFoam
// (icoUncoupledKinematicParticleFoam)
type MPPICCloud; // As "cloud" but with MPPIC
// collision modelling. Same as the
// cloud previously used by
// MPPICFoam.
type thermoCloud; // As "cloud" but with
// thermodynamic modelling and heat
// transfer with the carrier phase.
// Same as the limestone cloud
// previously used by
// coalChemistryFoam.
type reactingCloud; // As "thermoCloud" but with phase
// change and mass transfer
// coupling with the carrier
// phase. Same as the cloud
// previously used in fireFoam.
type reactingMultiphaseCloud; // As "reactingCloud" but with
// particles that contain multiple
// phases. Same as the clouds
// previously used in
// reactingParcelFoam and
// simpleReactingParcelFoam and the
// coal cloud used in
// coalChemistryFoam.
type sprayCloud; // As "reactingCloud" but with
// additional spray-specific
// collision and breakup modelling.
// Same as the cloud previously
// used in sprayFoam and
// engineFoam.
The first three clouds are not thermally coupled, so are available in
all Lagrangian solvers. The last four are thermally coupled and require
access to the carrier thermodynamic model, so are only available in
compressible Lagrangian solvers.
This change has reduced the number of solvers necessary to provide the
same functionality; solvers that previously differed only in their
Lagrangian modelling can now be combined. The Lagrangian solvers have
therefore been consolidated with consistent naming as follows.
denseParticleFoam: Replaces DPMFoam and MPPICFoam
reactingParticleFoam: Replaces sprayFoam and coalChemistryFoam
simpleReactingParticleFoam: Replaces simpleReactingParcelFoam
buoyantReactingParticleFoam: Replaces reactingParcelFoam
fireFoam and engineFoam remain, although fireFoam is likely to be merged
into buoyantReactingParticleFoam in the future once the additional
functionality it provides is generalised.
Some additional minor functionality has also been added to certain
solvers:
- denseParticleFoam has a "cloudForceSplit" control which can be set in
system/fvOptions.PIMPLE. This provides three methods for handling the
cloud momentum coupling, each of which have different trade-off-s
regarding numerical artefacts in the velocity field. See
denseParticleFoam.C for more information, and also bug report #3385.
- reactingParticleFoam and buoyantReactingParticleFoam now support
moving mesh in order to permit sharing parts of their implementation
with engineFoam.
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.
