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 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.
Description
Stops the run when the specified clock time in second has been reached
and optionally write results before stopping.
The following actions are supported:
- noWriteNow
- writeNow
- nextWrite (default)
Examples of function object specification:
\verbatim
stop
{
type stopAtClockTime;
libs ("libutilityFunctionObjects.so");
stopTime 10;
action writeNow;
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtClockTime | yes |
stopTime | Maximum elapsed time [s] | yes |
action | Action executed | no | nextWrite
\endtable
By default the case stops following the next write but stopping immediately with
or without writing are also options.
The stopAtFile functionObject derived from stopAt stops the run when a file
predefined file is created in the case directory:
Description
Stops the run when the specified file is created in the case directory.
The default name of the trigger file is \c $FOAM_CASE/<name> where \c
<name> is the name of the functionObject entry and the default action is \c
nextWrite.
Currently the following action types are supported:
- noWriteNow
- writeNow
- nextWrite
Examples of function object specification:
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
}
\endverbatim
will stop the run at the next write after the file "stop" is created in the
case directory.
\verbatim
stop
{
type stopAtFile;
libs ("libutilityFunctionObjects.so");
file "$FOAM_CASE/stop";
action writeNow;
}
\endverbatim
will write the fields and stop the run when the file "stop" is created in
the case directory.
Usage
\table
Property | Description | Required | Default value
type | type name: stopAtFile | yes |
file | Trigger file path name | no | $FOAM_CASE/<name>
action | Action executed | no | nextWrite
\endtable
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.
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.
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.
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.
Paraview 5.7.0+ has a bug relating to polygon and line offsetting which
means that when viewing a "Surface With Edges" representation at high
zoom excessive amounts of edges that should not be visible are shown.
This makes inspection of a typical mesh almost impossible.
See issues 19723 and 19437 on ParaView's gitlab.
Downgrading to version 5.6.3 until this issue is resolved.
PVReaders now support compilation against ParaView version 5.7.0 and
greater. All references to ParaView versions less than 4.0.0 have been
removed.
Based on a patch contributed by CFD Support
providing the shear-stress term in the momentum equation for incompressible and
compressible Newtonian, non-Newtonian and visco-elastic laminar flow as well as
Reynolds averaged and large-eddy simulation of turbulent flow.
The general deviatoric shear-stress term provided by the MomentumTransportModels
library is named divDevTau for compressible flow and divDevSigma (sigma =
tau/rho) for incompressible flow, the spherical part of the shear-stress is
assumed to be either included in the pressure or handled separately. The
corresponding stress function sigma is also provided which in the case of
Reynolds stress closure returns the effective Reynolds stress (including the
laminar contribution) or for other Reynolds averaged or large-eddy turbulence
closures returns the modelled Reynolds stress or sub-grid stress respectively.
For visco-elastic flow the sigma function returns the effective total stress
including the visco-elastic and Newtonian contributions.
For thermal flow the heat-flux generated by thermal diffusion is now handled by
the separate ThermophysicalTransportModels library allowing independent run-time
selection of the heat-flux model.
During the development of the MomentumTransportModels library significant effort
has been put into rationalising the components and supporting libraries,
removing redundant code, updating names to provide a more logical, consistent
and extensible interface and aid further development and maintenance. All
solvers and tutorials have been updated correspondingly and backward
compatibility of the input dictionaries provided.
Henry G. Weller
CFD Direct Ltd.
Following the generalisation of the TurbulenceModels library to support
non-Newtonian laminar flow including visco-elasticity and extensible to other
form of non-Newtonian behaviour the name TurbulenceModels is misleading and does
not properly represent how general the OpenFOAM solvers now are. The
TurbulenceModels now provides an interface to momentum transport modelling in
general and the plan is to rename it MomentumTransportModels and in preparation
for this the turbulenceProperties dictionary has been renamed momentumTransport
to properly reflect its new more general purpose.
The old turbulenceProperties name is supported for backward-compatibility.
Rather than specifying the controls per field it is simpler to use a single set
of controls for all the fields in the list and use separate instances of the
fieldAverage functionObject for different control sets:
Example of function object specification setting all the optional parameters:
fieldAverage1
{
type fieldAverage;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
restartOnRestart false;
restartOnOutput false;
periodicRestart false;
restartPeriod 0.002;
base time;
window 10.0;
windowName w1;
mean yes;
prime2Mean yes;
fields (U p);
}
This allows for a simple specification with the optional prime2Mean entry using
#includeFunc fieldAverage(U, p, prime2Mean = yes)
or if the prime2Mean is not needed just
#includeFunc fieldAverage(U, p)
To handle the additional optional specification for the closeness calculation
these settings are now is a sub-dictionary of surfaceFeaturesDict, e.g.
closeness
{
// Output the closeness of surface elements to other surface elements.
faceCloseness no;
// Output the closeness of surface points to other surface elements.
pointCloseness yes;
// Optional maximum angle between opposite points considered close
internalAngleTolerance 80;
externalAngleTolerance 80;
}
to support the more convenient #includeFunc specification in both
#includeFunc fieldAverage(U.air, U.water, alpha.air, p)
and
#includeFunc fieldAverage(fields = (U.air, U.water, alpha.air, p))
forms.
The mean, prime2Mean and base now have default values:
{
mean on; // (default = on)
prime2Mean on; // (default = off)
base time; // time or iteration (default = time)
window 200; // optional averaging window
windowName w1; // optional window name (default = "")
}
so for the majority of cases for which these defaults are appropriate the
fieldAverage functionObject can now be specified in the functions entry in
controlDict thus:
functions
{
fieldAverage1
{
#includeEtc "caseDicts/postProcessing/fields/fieldAverage.cfg"
fields
(
U.air
U.water
alpha.air
p
);
}
}
also utilising the new fieldAverage.cfg file.
For cases in which these defaults are not appropriate, e.g. the prime2Mean is
also required the optional entries can be specified within sub-dictionaries for
each field, e.g.
fieldAverage1
{
#includeEtc "caseDicts/postProcessing/fields/fieldAverage.cfg"
fields
(
U
{
prime2Mean yes;
}
p
{
prime2Mean yes;
}
);
}
The total enthalpy is calculated as
Ha = ha + K
where
ha is absolute enthalpy
K is the kinetic energy: 1/2*magSqr(U)
The total enthalpy or a particular phase can be calculated by specifying the
optional "phase" name, e.g.
#includeFunc totalEnthalpy(phase = liquid)
The utilised static parts of polyMeshGeometry are now part of a
polyMeshCheck namespace. Everything else has been removed, as they were
unused, out of date, and/or duplicated elsewhere.
For example in the new tutorial case:
tutorials/incompressible/pimpleFoam/laminar/pitzDailyPulse
a cosine bell velocity pulse is specified at the inlet by directly defining the
code for it:
inlet
{
type uniformFixedValue;
uniformValue coded;
name pulse;
codeInclude
#{
#include "mathematicalConstants.H"
#};
code
#{
return vector
(
0.5*(1 - cos(constant::mathematical::twoPi*min(x/0.3, 1))),
0,
0
);
#};
}
which is then compiled automatically and linked into the running pimpleFoam
dynamically and executed to set the inlet velocity.
For complex geometries the calculation of surface face and point "closeness" can
be quite time consuming and usually only one or other is required; the new
options allow the user to specify which should be calculated and written.
All of the film transport equations are now formulated with respect to the film
volume fraction in the region cell layer rather than the film thickness which
ensures mass conservation of the film even as it flows over curved surfaces and
around corners. (In the previous formulation the conservation error could be as
large as 15% for a film flowing around a corner.)
The film Courant number is now formulated in terms of the film cell volumetric
flux which avoids the stabilised division by the film thickness and provides a
more reliable estimate for time-step evaluation. As a consequence the film
solution is substantially more robust even though the time-step is now
significantly higher. For film flow dominated problem the simulations now runs
10-30x faster.
The inconsistent extended PISO controls have been replaced by the standard
PIMPLE control system used in all other flow solvers, providing consistent
input, a flexible structure and easier maintenance.
The momentum corrector has been re-formulated to be consistent with the momentum
predictor so the optional PIMPLE outer-corrector loop converges which it did not
previously.
nonuniformTransformCyclic patches and corresponding fields are no longer needed
and have been removed which paves the way for a future rationalisation of the
handling of cyclic transformations in OpenFOAM to improve robustness, usability
and maintainability.
Film sources have been simplified to avoid the need for fictitious boundary
conditions, in particular mappedFixedPushedInternalValueFvPatchField which has
been removed.
Film variables previously appended with an "f" for "film" rather than "face"
have been renamed without the unnecessary and confusing "f" as they are
localised to the film region and hence already directly associated with it.
All film tutorials have been updated to test and demonstrate the developments
and improvements listed above.
Henry G. Weller
CFD Direct Ltd.
This change formalises the usage of the "log" keyword in function
objects. By default, logging to stdout is activated when running
"postProcess" or "<solver> -postProcess", and deactivated when a
function is being executed as part of a run.
This behaviour can now be overridden in the function object dictionary
when operating in either mode.
