Provided for use with mixture turbulence models in interFoam and
compressibleInterFoam.
Class
Foam::fv::VoFTurbulenceDamping
Description
Free-surface turbulence damping function
Adds an extra source term to the mixture or phase epsilon or omega
equation to reduce turbulence generated near a free-surface. The
implementation is based on
Reference:
\verbatim
Frederix, E. M. A., Mathur, A., Dovizio, D., Geurts, B. J.,
& Komen, E. M. J. (2018).
Reynolds-averaged modeling of turbulence damping
near a large-scale interface in two-phase flow.
Nuclear engineering and design, 333, 122-130.
\endverbatim
but with an improved formulation for the coefficient \c A appropriate for
unstructured meshes including those with split-cell refinement patterns.
However the dimensioned length-scale coefficient \c delta remains and must
be set appropriatly for the case by performing test runs and comparing with
known results. Clearly this model is far from general and more research is
needed in order that \c delta can be obtained directly from the interface
flow and turbulence conditions.
Usage
Example usage:
\verbatim
VoFTurbulenceDamping
{
type VoFTurbulenceDamping;
libs ("libVoFTurbulenceDamping.so");
// Interface turbulence damping length scale
// This is a required input as described in section 3.3 of the paper
delta 1e-4;
// phase water; // Optional phase name
}
\endverbatim
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
and only needed if there is a name clash between entries in the source
specification and the set specification, e.g. "name":
{
name rotorCells;
type cellSet;
action new;
source zoneToCell;
sourceInfo
{
name cylinder;
}
}
topoSet is a more flexible and extensible replacement for setSet using standard
OpenFOAM dictionary input format rather than the limited command-line input
format developed specifically for setSet. This replacement allows for the
removal of a significant amount of code simplifying maintenance and the addition
of more topoSet sources.
Settings for the particleTracks utility are now specified in
system/particleTracksDict. Correspondingly, settings for
steadyParticleTracks are now specified in
system/steadyParticleTracksDict.
The -dict option is now handled correctly and consistently across all
applications with -dict options. The logic associated with doing so has
been centralised.
If a relative path is given to the -dict option, then it is assumed to
be relative to the case directory. If an absolute path is given, then it
is used without reference to the case directory. In both cases, if the
path is found to be a directory, then the standard dictionary name is
appended to the path.
Resolves bug report http://bugs.openfoam.org/view.php?id=3692
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.
When using 'simple' or 'hierarchical' decomposition it is useful to slightly rotate a
coordinate-aligned block-mesh to improve the processor boundaries by avoiding
irregular cell distribution at those boundaries. The degree of slight rotation
is controlled by the 'delta' coefficient and a value of 0.001 is generally
suitable so to avoid unnecessary clutter in 'decomposeParDict' 'delta' now
defaults to this value.
The new algorithm provides robust quality triangulations of non-convex
polygons. It also produces a best attempt for polygons that are badly
warped or self intersecting by minimising the area in which the local
normal is in the opposite direction to the overal polygon normal. It is
memory efficient when applied to multiple polygons as it maintains and
reuses its workspace.
This algorithm replaces implementations in the face and
faceTriangulation classes, which have been removed.
Faces can no longer be decomposed into mixtures of tris and
quadrilaterals. Polygonal faces with more than 4 sides are now
decomposed into triangles in foamToVTK and in paraFoam.
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.
