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.
While calculatedFvPatchField would be considered as a BC which fixes the value
during solution it cannot be used for that purpose and under all other
conditions it does not fix the boundary value as the '=' operator changes the
value. However calculatedFvPatchField is used for the reference phase in
multiphase systems and if it is considered to fix the boundary value it interferes
with the operation of the MULES limiter and hence it is far preferable if it
does not fix the value.
Solid thermo no longer requires a pressure field, so solid regions of
chtMultiRegionFoam cases no longer need a 0/<solidRegionName>/p file.
In order for solidThermo to continue to use heThermo and the low level
thermo classes, it now constructs a uniformGeometricScalarField for the
pressure with the value NaN. This is passed into the low-level thermo
models by heThermo. The enforces the requirement that low-level thermo
models used by solidThermo should have no pressure dependence. If an
instantiation is made with pressure dependence, the code will fail with
a floating point error.
This turbulence model is described in:
\verbatim
Walters, D. K., & Cokljat, D. (2008).
A three-equation eddy-viscosity model for Reynolds-averaged
Navier–Stokes simulations of transitional flow.
Journal of Fluids Engineering, 130(12), 121401.
\endverbatim
corrected according to:
\verbatim
Furst, J. (2013).
Numerical simulation of transitional flows with laminar kinetic energy.
Engineering Mechanics, 20(5), 379-388.
\endverbatim
and includes the improvements proposed in:
\verbatim
Lopez, M., and Keith Walters, D. (2016).
A Recommended Correction to the kT−kL−ω Transition-Sensitive
Eddy-Viscosity Model.
Journal of Fluids Engineering, 139(2), 024501.
\endverbatim
This turbulence model is described in:
\verbatim
Walters, D. K., & Cokljat, D. (2008).
A three-equation eddy-viscosity model for Reynolds-averaged
Navier–Stokes simulations of transitional flow.
Journal of Fluids Engineering, 130(12), 121401.
\endverbatim
corrected according to:
\verbatim
Furst, J. (2013).
Numerical simulation of transitional flows with laminar kinetic energy.
Engineering Mechanics, 20(5), 379-388.
\endverbatim
and includes the improvements proposed in:
\verbatim
Lopez, M., and Keith Walters, D. (2016).
A Recommended Correction to the kT−kL−ω Transition-Sensitive
Eddy-Viscosity Model.
Journal of Fluids Engineering, 139(2), 024501.
\endverbatim
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.
There is now only one -listSwitches argument available to the
applications; -listUnsetSwitches and -listRegisteredSwitches have been
removed. -listSwitches prints everything, now also including the values.
It also categorises the output based on whether the switch has a
default, if it has the same value as that default, and whether or not it
is registered with a re-reader.
The list of debug switches in etc/controlDict has been reduced to only
the switches which have non-zero values. In general the list of valid
switches varies per application and per library, so it is not possible
to keep a single definitive list of all switches. The -listSwitches
argument provides the definitive list on a per applicaton basis.
Setting of defaults for named enum optimisation switches has been added.
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.
