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.
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.
This means a plane can now be specified like this:
planeType pointAndNormal;
point (0 0 0);
normal (0 0 1);
As well as this:
planeType pointAndNormal;
pointAndNormalDict
{
point (0 0 0);
normal (0 0 1);
}
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.
gcc version 5 and above and clang version 3.4 and above fully support the C++14
standard and the compilation rules of OpenFOAM-dev now require this support
allowing for further development and maintenance to benefit from the additional
language features provided in C++14.
For example
thermo:rho.air1
{
explicit 3e-07;
implicit 0;
}
f1.air1.bubbles
{
value 3.5;
explicit #calc "$value*$../thermo:rho.air1/explicit";
implicit 0;
}
now works, whereas previously an extra level of '../' was required:
explicit #calc "$value*$../../thermo:rho.air1/explicit";
because #calc created its own sub-dictionary. The '$value' would have also
needed a '../' except that the 'value' entry is in the direct parent and could
be looked-up automatically by the parent search.
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.
