For example, 'foamInfo RosinRammler' includes in the output:
Model
This appears to be the 'RosinRammler' model of the 'distributionModels' family.
The models in the 'distributionModels' family are:
+ exponential
+ fixedValue
+ general
+ massRosinRammler
+ multiNormal
+ normal
+ RosinRammler
+ uniform
to avoid further confusion from users migrating from very old OpenFOAM versions.
The surfaceFeatureExtract utility has been superseded and replaced by by the
more general surfaceFeatures utility.
surfaceFeatures reads a surfaceFeaturesDict input file with a much
simpler, more convenient format. Example surfaceFeaturesDict files
can be found in the tutorial and template cases, e.g. located as
follows:
find \$FOAM_TUTORIALS -name surfaceFeaturesDict
find \$FOAM_ETC -name surfaceFeaturesDict
The generation script has also been modified slightly to prevent empty
entries being generated for scripts with no options; e.g., the scripts
in $WM_PROJECT_DIR/bin that report a change in application name
splitBaffles identifies baffle faces; i.e., faces on the mesh boundary
which share the exact same set of points as another boundary face. It
then splits the points to convert these faces into completely separate
boundary patches. This functionality was previously provided by calling
mergeOrSplitBaffles with the "-split" option.
mergeBaffles also identifes the duplicate baffle faces, but then merges
them, converting them into a single set of internal faces. This
functionality was previously provided by calling mergeOrSplitBaffles
without the "-split" option.
The fireFoam solver has solver has been replaced by the more general
buoyantReactingFoam solver, which supports buoyant compressible reacting flow
coupled to multiple run-time-selectable lagrangian clouds and surface film
modelling and optional hydrostatic initialisation of the pressure and p_rgh.
Hydrostatic initialisation of the pressure fields is useful for large fires in
open domains where the stability of the initial flow is dominated by the initial
pressure distribution in the domain and at the boundaries. The optional
hydrostaticInitialization switch in fvSolution/PIMPLE with
nHydrostaticCorrectors enables hydrostatic initialisation, e.g.
PIMPLE
{
momentumPredictor yes;
nOuterCorrectors 1;
nCorrectors 2;
nNonOrthogonalCorrectors 0;
hydrostaticInitialization yes;
nHydrostaticCorrectors 5;
}
and the resulting ph_rgh field can be used with the prghTotalHydrostaticPressure
p_rgh boundary condition to apply this hydrostatic pressure distribution at the
boundaries throughout the simulation.
See the following cases for examples transferred from fireFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/RAS
With the new fvModels framework it is now possible to implement complex models
and wrappers around existing complex models which can then be optionally
selected in any general solver which provides compatible fields and
thermophysical properties. This simplifies code development and maintenance by
significantly reducing complex code duplication and also provide the opportunity
of running these models in other solvers without the need for code duplication
and alteration.
The immediate advantage of this development is the replacement of the
specialised Lagrangian solvers with their general counterparts:
reactingParticleFoam -> reactingFoam
reactingParcelFoam -> reactingFoam
sprayFoam -> reactingFoam
simpleReactingParticleFoam -> reactingFoam
buoyantReactingParticleFoam -> buoyantReactingFoam
For example to run a reactingParticleFoam case in reactingFoam add the following
entries in constant/fvModels:
buoyancyForce
{
type buoyancyForce;
}
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
which add the acceleration due to gravity needed by Lagrangian clouds and the
clouds themselves.
See the following cases for examples converted from reactingParticleFoam:
$FOAM_TUTORIALS/combustion/reactingFoam/Lagrangian
and to run a buoyantReactingParticleFoam case in buoyantReactingFoam add the
following entry constant/fvModels:
clouds
{
type clouds;
libs ("liblagrangianParcel.so");
}
to add support for Lagrangian clouds and/or
surfaceFilm
{
type surfaceFilm;
libs ("libsurfaceFilmModels.so");
}
to add support for surface film. The buoyancyForce fvModel is not required in
this case as the buoyantReactingFoam solver has built-in support for buoyancy
utilising the p_rgh formulation to provide better numerical handling for this
force for strongly buoyancy-driven flows.
See the following cases for examples converted from buoyantReactingParticleFoam:
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian
All the tutorial cases for the redundant solvers have been updated and converted
into their new equivalents and redirection scripts replace these solvers to
provide users with prompts on which solvers have been replaced by which and
information on how to upgrade their cases.
To support this change and allow all previous Lagrangian tutorials to run as
before the special Lagrangian solver fvSolution/PIMPLE control
solvePrimaryRegion has been replaced by the more general and useful controls:
models : Enable the fvModels
thermophysics : Enable thermophysics (energy and optional composition)
flow : Enable flow (pressure/velocity system)
which also replace the fvSolution/PIMPLE control frozenFlow present in some
solvers. These three controls can be used in various combinations to allow for
example only the fvModels to be evaluated, e.g. in
$FOAM_TUTORIALS/combustion/buoyantReactingFoam/Lagrangian/rivuletPanel
PIMPLE
{
models yes;
thermophysics no;
flow no;
.
.
.
so that only the film is solved. Or during the start-up of a case it might be
beneficial to run the pressure-velocity system for a while without updating
temperature which can be achieved by switching-off thermophysics. Also the
behaviour of the previous frozenFlow switch can be reproduced by switching flow
off with the other two switches on, allowing for example reactions, temperature
and composition update without flow.
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
This replaces compressibleInterFilmFoam in a more flexible, general and easily
maintainable form. A compressibleInterFilmFoam script is provided to redirect
uses to the replacement functionality:
The compressibleInterFilmFoam solver has solver has been replaced by the more general
compressibleInterFoam solver, which now supports surface films using the new
VoFSurfaceFilm fvOption.
To run with with surface film create a system/fvOptions dictionary
containing the VoFSurfaceFilm specification, e.g.
VoFSurfaceFilm
{
type VoFSurfaceFilm;
phase water;
}
The phase-change functionality in interPhaseChangeFoam has been generalised and
moved into the run-time selectable twoPhaseChange library included into
interFoam providing optional phase-change. The three cavitation models provided
in interPhaseChangeFoam are now included in the twoPhaseChange library and the
two interPhaseChangeFoam cavitation tutorials updated for interFoam.
interPhaseChangeFoam has been replaced by a user redirection script which prints
the following message:
The interPhaseChangeFoam solver has solver has been replaced by the more general
interFoam solver, which now supports phase-change using the new twoPhaseChange
models library.
To run with with phase-change create a constant/phaseChangeProperties dictionary
containing the phase-change model specification, e.g.
phaseChangeModel SchnerrSauer;
pSat 2300; // Saturation pressure
See the following cases for an example converted from interPhaseChangeFoam:
$FOAM_TUTORIALS/multiphase/interFoam/laminar/cavitatingBullet
$FOAM_TUTORIALS/multiphase/interFoam/RAS/propeller
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.
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.
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.
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.
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
This script allows version numbers to be compared. It is called in the
following way:
foamVersionCompare <version-1> <comparison> <version-2>
The <comparison> argument can be one of; eq (equal-to), lt (less-than),
gt (greater-than), le (less-than-or-equal-to), or ge
(greater-than-or-equal-to). The script returns a successful exit code if
the comparison evaluates as true.
Example usage:
if $WM_PROJECT_DIR/bin/tools/foamVersionCompare 5.4.3 gt 5.5.1
then
echo "5.4.3 IS greater than 5.5.1"
else
echo "5.4.3 is NOT greater than 5.5.1"
fi
A number of file name patterns have been removed from the list of things
that cleanCase deletes. Some patterns related to obsolete files that
OpenFOAM no longer generates, and some were deemed too generic to
delete as they might contain important persistent information.
These cases now check for a mesh in geometrically identical cases and
copy rather than re-generate if possible. This reduces the run-time of
the test loop by about 20 minutes.
