Expanded the documentation and updated the mean free path calculation
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
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.
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.
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.
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.
foamDictionary executions are now wrapped by runApplication like any
other execution so that they do not print during a test loop.
foamDictionary does not produce a conforming log, however, so
log.foamDictionary has been filtered out of the formation of the test
loop report so that false failures are not reported.
The new optional 'slash' scoping syntax is now the default and provides a more
intuitive and flexible syntax than the previous 'dot' syntax, corresponding to
the common directory/file access syntax used in UNIX, providing support for
reading entries from other dictionary files.
In the 'slash' syntax
'/' is the scope operator
'../' is the parent dictionary scope operator
'!' is the top-level dictionary scope operator
Examples:
internalField 3.4;
active
{
type fixedValue;
value.air $internalField;
}
inactive
{
type anotherFixedValue;
value $../active/value.air;
anotherValue $!active/value.air;
sub
{
value $../../active/value.air;
anotherValue $!active/value.air;
}
}
"U.*"
{
solver GAMG;
}
e.air
{
$U.air;
}
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
If there is a part of the keyword before the '!' then this is taken to be the
file name of the dictionary from which the entry will be looked-up using the
part of the keyword after the '!'. For example given a file testSlashDict containing
internalField 5.6;
active
{
type fixedValue;
value.air $internalField;
}
entries from it can be read directly from another file, e.g.
external
{
value $testSlashDict2!active/value.air;
}
active2
{
$testSlashDict2!active;
}
which expands to
external
{
value 5.6;
}
active2
{
type fixedValue;
value.air 5.6;
}
These examples are provided in applications/test/dictionary.
The the default syntax can be changed from 'slash' to 'dot' in etc/controlDict
to revert to the previous behaviour:
OptimisationSwitches
{
.
.
.
// Default dictionary scoping syntax
inputSyntax slash; // Change to dot for previous behaviour
}
or within a specific dictionary by adding the entry
See applications/test/dictionary/testDotDict.
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.
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.
A new family of interface compression interpolation schemes based on
piecewise-linear interface calculation (PLIC). PLIC represents an interface by
surface-cuts which split each cell to match the volume fraction of the phase in
that cell. The surface-cuts are oriented according to the point field of the
local phase fraction. The phase fraction on each cell face — the interpolated
value — is then calculated from the amount submerged below the surface-cut.
The basic PLIC method generates a single cut so cannot handle cells in which
there are multiple interfaces or where the interface is not fully resolved. In
those cells, the interpolation reverts to an alternative scheme, typically
standard interface compression. PLIC, with a fallback to interface compression,
produces robust solutions for real engineering cases. It can run with large time
steps so can solve problems like hydrodynamics of a planing hull, with rigid
body motion of the hull (above). The user selects PLIC by the following setting
in fvSchemes:
div(phi,alpha) Gauss PLIC interfaceCompression vanLeer 1;
The multicut PLIC (MPLIC) scheme extends PLIC to handle multiple
surface-cuts. Where a single cut is insufficient, MPLIC performs a topological
face-edge-face walk to produce multiple splits of a cell. If that is still
insufficient, MPLIC decomposes the cell into tetrahedrons on which the cuts are
applied. The extra cutting carries an additional computational cost but requires
no fallback. The user selects MPLIC by the following setting in the fvSchemes
file:
div(phi,alpha) Gauss MPLIC;
Variants of the PLIC and MPLIC schemes are also available which use velocities
at the face points to calculate the face flux. These PLICU and MPLICU schemes
are likely to be more accurate in regions of interface under high shear.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Jakub Knir
CFD Direct Ltd.
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.
Only perfectGas and real-gas equations of state are consistent with standard
Janaf thermo data based on Cp. Using other equations of state is possible but
the Janaf Cp data would have to be modified for consistency.
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.
Added a local copy of the $FOAM_TUTORIALS/resources/blockMesh/pitzDaily
corresponding to the OpenFOAM test instructions.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3497
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.
