The FOAM file format has not changed from version 2.0 in many years and so there
is no longer a need for the 'version' entry in the FoamFile header to be
required and to reduce unnecessary clutter it is now optional, defaulting to the
current file format 2.0.
The writer class has been renamed setWriter in order to clarify its
usage. The coordSet and setWriter classes have been moved into the
sampling library, as this fits their usage.
The new write functions are currently being utilised by setSet and the
vtkSurfaceWriter, but it should eventually be possible for more examples
of VTK poly data writing to be converted to use these functions.
the previous naming tan1, tan2, normal was non-intuitive and very confusing.
It was not practical to maintain backward compatibility but all tutorials and
example refineMeshDict files have been updated to provide examples of the
change.
to ensure that the contact angle specification is used irrespective of which
phase it is specified in. An error is reported if both phases of the interface
pair have a contact angle specification as the specifications might be
inconsistent.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3688
to ensure that the contact angle specification is used irrespective of which
phase it is specified in. An error is reported if both phases of the interface
pair have a contact angle specification as the specifications might be
inconsistent.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3688
The pressure work term for total internal energy is div(U p) which can be
discretised is various ways, given a mass flux field phi it seems logical to
implement it in the form div(phi/interpolate(rho), p) but this is not exactly
consistent with the relationship between enthalpy and internal energy (h = e +
p/rho) and the transport of enthalpy, it would be more consistent to implement
it in the form div(phi, p/rho). A further improvement in consistency can be
gained by using the same convection scheme for this work term and the convection
term div(phi, e) and for reacting solvers this is easily achieved by using the
multi-variate limiter mvConvection provided for energy and specie convection.
This more consistent total internal energy work term has now been implemented in
all the compressible and reacting flow solvers and provides more accurate
solutions when running with internal energy, particularly for variable density
mixing cases with small pressure variation.
For non-reacting compressible solvers this improvement requires a change to the
corresponding divScheme in fvSchemes:
"div\(alphaPhi.*,p\)" -> "div\(alphaRhoPhi.*,\(p\|thermo:rho.*\)\)"
and all the tutorials have been updated accordingly.
The pressure work term for total internal energy is div(U p) which can be
discretised is various ways, given a mass flux field phi it seems logical to
implement it in the form div(phi/interpolate(rho), p) but this is not exactly
consistent with the relationship between enthalpy and internal energy (h = e +
p/rho) and the transport of enthalpy, it would be more consistent to implement
it in the form div(phi, p/rho). A further improvement in consistency can be
gained by using the same convection scheme for this work term and the convection
term div(phi, e) and for reacting solvers this is easily achieved by using the
multi-variate limiter mvConvection provided for energy and specie convection.
This more consistent total internal energy work term has now been implemented in
all the compressible and reacting flow solvers and provides more accurate
solutions when running with internal energy, particularly for variable density
mixing cases with small pressure variation.
For non-reacting compressible solvers this improvement requires a change to the
corresponding divScheme in fvSchemes:
div(phiv,p) -> div(phi,(p|rho))
and all the tutorials have been updated accordingly.
Class
Foam::hydrostaticInitialisation
Description
Optional hydrostatic initialisation of p_rgh and p by solving for and
caching the hydrostatic ph_rgh and updating the density such that
p = ph_rgh + rho*gh + pRef
This initialisation process is applied at the beginning of the run (not on
restart) if the \c hydrostaticInitialisation switch is set true in
fvSolution/PIMPLE or fvSolution/SIMPLE. The calculation is iterative if the
density is a function of pressure and an optional number of iterations \c
nHydrostaticCorrectors may be specified which defaults to 5.
Class
Foam::hydrostaticInitialisation
Description
Optional hydrostatic initialisation of p_rgh and p by solving for and
caching the hydrostatic ph_rgh and updating the density such that
p = ph_rgh + rho*gh + pRef
This initialisation process is applied at the beginning of the run (not on
restart) if the \c hydrostaticInitialisation switch is set true in
fvSolution/PIMPLE or fvSolution/SIMPLE. The calculation is iterative if the
density is a function of pressure and an optional number of iterations \c
nHydrostaticCorrectors may be specified which defaults to 5.
Field algebra has been optimised by careful ordering to minimise the
number of expensive operations; e.g., changing a/b/c to a/(b*c) in order
to minimise the number of divisions.
Some minor consistency improvements have also been made throughout
population balance.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
A phase system has been added that combines interface composition phase
change modelling and population balance modelling. It can be selected in
constant/phaseProperties using the following setting:
type interfaceCompositionPhaseChangePopulationBalanceMultiphaseSystem;
In order to facilitate the operation of population balance models with
mass transfers generated by the interface composition system, the full
interfacial mass transfer rate is now being stored, as well as the
linearised specie transfers. This means the mass transfer rates
associated with the interface composition mechanism can be looked up and
utilised by sub models.
Based on a patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
for buoyant solvers buoyantPimpleFoam, buoyantSimpleFoam and
buoyantReactingFoam:
Class
Foam::hydrostaticInitialisation
Description
Optional hydrostatic initialisation of p_rgh and p by solving for and
caching the hydrostatic ph_rgh and updating the density such that
p = ph_rgh + rho*gh + pRef
This initialisation process is applied at the beginning of the run (not on
restart) if the \c hydrostaticInitialisation switch is set true in
fvSolution/PIMPLE or fvSolution/SIMPLE. The calculation is iterative if the
density is a function of pressure and an optional number of iterations \c
nHydrostaticCorrectors may be specified which defaults to 5.
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 phase-fraction filtering of the compressibility terms is present to avoid
spurious phase-change due to numerical noise. The fvModels contribution may
cause physical phase-change due to cavitation, boiling, transfer from film or
VoF even where none of the phase is present and hence must be added after the
compressibility filtering.
With VoFClouds and VoFSurfaceFilm compressibleInterFoam supports Lagrangian
clouds which can impinge on walls forming a film which in turn can transfer to
the VoF when the film is thick enough to resolve. The new tutorial case
tutorials/multiphase/compressibleInterFoam/laminar/cylinder
is provided to demonstrate this functionality.
Direct transfer of droplets to the VoF phase is not yet supported but will be
added later.
The reduced SLGThermo has been renamed parcelThermo to better represent the
purpose.
parcelThermo is not created and stored in the cloud that requires it rather than
requiring it to be created in the solver createFields and passed to the cloud on
construction.
This makes usage of transformPoints the same as for
surfaceTransformPoints. Transformations are supplied as a string and are
applied in sequence.
Usage
transformPoints "\<transformations\>" [OPTION]
Supported transformations:
- "translate=<translation vector>"
Translational transformation by given vector
- "rotate=(<n1 vector> <n2 vector>)"
Rotational transformation from unit vector n1 to n2
- "Rx=<angle [deg] about x-axis>"
Rotational transformation by given angle about x-axis
- "Ry=<angle [deg] about y-axis>"
Rotational transformation by given angle about y-axis
- "Rz=<angle [deg] about z-axis>"
Rotational transformation by given angle about z-axis
- "Ra=<axis vector> <angle [deg] about axis>"
Rotational transformation by given angle about given axis
- "scale=<x-y-z scaling vector>"
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
transformPoints \
"translate=(-0.05 -0.05 0), \
Rz=45, \
translate=(0.05 0.05 0)"
Now the VoFSurfaceFilm library is optionally loaded at run-time for cases that
require surface film by adding the optional "libs" entry in controlDict:
libs ("libVoFSurfaceFilm.so");
See tutorials/multiphase/compressibleInterFoam/laminar/plateFilm
Now the VoFSurfaceFilm library is optionally loaded at run-time for cases that
require surface film by adding the optional "libs" entry in controlDict:
libs ("libVoFSurfaceFilm.so");
See tutorials/multiphase/compressibleInterFoam/laminar/plateFilm
in particular for equations of state which do not support coefficient mixing
required by equilibrium constant evaluation in reactions.
Also improved the set of pre-compiled combinations of properties and mixing
rules.
To provide more flexibility, extensibility, run-time modifiability and
consistency the handling of optional pressure limits has been moved from
pressureControl (settings in system/fvSolution) to the new limitPressure
fvConstraint (settings in system/fvConstraints).
All tutorials have been updated which provides guidance when upgrading cases but
also helpful error messages are generated for cases using the old settings
providing specific details as to how the case should be updated, e.g. for the
tutorials/compressible/rhoSimpleFoam/squareBend case which has the pressure
limit specification:
SIMPLE
{
...
pMinFactor 0.1;
pMaxFactor 2;
...
generates the error message
--> FOAM FATAL IO ERROR:
Pressure limits should now be specified in fvConstraints:
limitp
{
type limitPressure;
minFactor 0.1;
maxFactor 2;
}
file: /home/dm2/henry/OpenFOAM/OpenFOAM-dev/tutorials/compressible/rhoSimpleFoam/squareBend/system/fvSolution/SIMPLE from line 41 to line 54.
Now that dynamic compilation of thermo and chemistry is available it is no
longer necessary or useful to instantiate vast numbers of thermo combinations
within the standard OpenFOAM libraries. This reduces compile time, library size
and simplifies maintenance.
divU is cached before mesh-motion and mapped post-motion to drive the optional pcorr flux
update to ensure the fluxes are conservative following mesh motion and change.
The phase system now have the ability to specify the derivative of mass
transfer rates w.r.t. pressure. This permits implicit handling of
pressure-coupled mass transfer processes.
This implicit handling has been applied to the mass transfers that are
modelled by the thermal phase system. This should result in significant
stability improvements. The implicit handling can be toggled on or off
by means of a "pressureImplicit" switch in constant/phaseProperties. It
is on by default.
Patch contributed by Juho Peltola, VTT.
The former implementation of the daughterSizeDistributionModel based on
Laakkonen et al. (2006) had the issue of not conserving the total
particle number and volume properly, except when the coefficient C4 is
set to a value of 2. The issue is solved by following the work of
Laakkonen et al. (2007).
The default coefficients in both the breakupModel and the
daughterSizeDistributionModel were updated as well according to the
suggestions of the authors.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
The current implementation of the uniform daughterSizeDistribution model
is not general enough to support uniform breakup into multiple fragments
while conserving both the total particle number and volume, except for
binary breakup (which was the default setting).
The model has therefore been renamed to uniformBinary, i.e. resulting in
two fragments.
It is currently used for verification purposes only. If the need for a
more general form arises, then that will require additional development.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
