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.
A new family of interface compression interpolation schemes based on
piecewise-linear interface calculation (PLIC). PLIC represents an interface by
surface-cuts which split each cell to match the volume fraction of the phase in
that cell. The surface-cuts are oriented according to the point field of the
local phase fraction. The phase fraction on each cell face — the interpolated
value — is then calculated from the amount submerged below the surface-cut.
The basic PLIC method generates a single cut so cannot handle cells in which
there are multiple interfaces or where the interface is not fully resolved. In
those cells, the interpolation reverts to an alternative scheme, typically
standard interface compression. PLIC, with a fallback to interface compression,
produces robust solutions for real engineering cases. It can run with large time
steps so can solve problems like hydrodynamics of a planing hull, with rigid
body motion of the hull (above). The user selects PLIC by the following setting
in fvSchemes:
div(phi,alpha) Gauss PLIC interfaceCompression vanLeer 1;
The multicut PLIC (MPLIC) scheme extends PLIC to handle multiple
surface-cuts. Where a single cut is insufficient, MPLIC performs a topological
face-edge-face walk to produce multiple splits of a cell. If that is still
insufficient, MPLIC decomposes the cell into tetrahedrons on which the cuts are
applied. The extra cutting carries an additional computational cost but requires
no fallback. The user selects MPLIC by the following setting in the fvSchemes
file:
div(phi,alpha) Gauss MPLIC;
Variants of the PLIC and MPLIC schemes are also available which use velocities
at the face points to calculate the face flux. These PLICU and MPLICU schemes
are likely to be more accurate in regions of interface under high shear.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Jakub Knir
CFD Direct Ltd.
A new run-time selectable interface compression scheme framework has been added
to the two-phase VoF solvers to provide greater flexibility, extensibility and
more consistent user-interface. The previously built-in interface compression
is now in the standard run-time selectable surfaceInterpolationScheme
interfaceCompression:
Class
Foam::interfaceCompression
Description
Interface compression corrected scheme, based on counter-gradient
transport, to maintain sharp interfaces during VoF simulations.
The interface compression is applied to the face interpolated field from a
suitable 2nd-order shape-preserving NVD or TVD scheme, e.g. vanLeer or
vanAlbada. A coefficient is supplied to control the degree of compression,
with a value of 1 suitable for most VoF cases to ensure interface integrity.
A value larger than 1 can be used but the additional compression can bias
the interface to follow the mesh more closely while a value smaller than 1
can lead to interface smearing.
Example:
\verbatim
divSchemes
{
.
.
div(phi,alpha) Gauss interfaceCompression vanLeer 1;
.
.
}
\endverbatim
The separate scheme for the interface compression term "div(phirb,alpha)" is no
longer required or used nor is the compression coefficient cAlpha in fvSolution
as this is now part of the "div(phi,alpha)" scheme specification as shown above.
Backward-compatibility is provided by checking the specified "div(phi,alpha)"
scheme against the known interface compression schemes and if it is not one of
those the new interfaceCompression scheme is used with the cAlpha value
specified in fvSolution.
More details can be found here:
https://cfd.direct/openfoam/free-software/multiphase-interface-capturing
Henry G. Weller
CFD Direct Ltd.
Only perfectGas and real-gas equations of state are consistent with standard
Janaf thermo data based on Cp. Using other equations of state is possible but
the Janaf Cp data would have to be modified for consistency.
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.
Added a local copy of the $FOAM_TUTORIALS/resources/blockMesh/pitzDaily
corresponding to the OpenFOAM test instructions.
Resolves bug-report https://bugs.openfoam.org/view.php?id=3497
All models that require templating on the thermodynamic model, including
the thermodynamic models themselves, are now instantiated using a
centralised set of variadic macros. Seven macros exist to instantiate
models for different classes of thermodynamics model. These are:
forGases: All model combinations valid for gases
forCommonGases: The most commonly used gas models
forAbsoluteGases: A limited selection of gas models with absolute
forms of energy, for use with Xi-combustion models
forLiquids: All model combinations valid for liquids
forCommonLiquids: The most commonly used liquid models
forPolynomials: Model combinations with properties fitted to
polynomials
forSolids: All model combinations valid for solids
All the *ThermoPhysics typedefs have been removed, as this system was
fundamentally not extensible. The enormous lists of thermodynamic
instantiations that existed for reaction thermos, chemistry models,
tabulation methods, etc..., were extremely difficult to read and reason
about what combinations are valid under what circumstances. This change
centralises those decisions, makes them concise and readable, and makes
them consistent across the entire codebase.
Soot model selection has now been brought up to date in line with
chemistry, combustion, and others. The angle-bracketed part of the name
is no longer necessary; this information is determined directly from the
existing thermo model. So, now to select a mixture-fraction soot model,
the entry is simply:
sootModel mixtureFraction;
Rather than:
sootModel mixtureFraction<rhoReactionThermo,gasHThermoPhysics>;
The only place in which *ThermoPhysics typedefs are still required in
the selection name is in the thermalBaffle1D boundary condition. Here
there is no thermo model from which to determine a name. This eventually
needs resolving either by adding a selection mechanism similar to that
of the thermo packages themselves, or by removing this boundary
condition in favour of the (non-1D) thermal baffle boundary condition
and region model.
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.
The simplistic energy transport support in compressibleTurbulenceModels has been
abstracted and separated into the new ThermophysicalTransportModels library in
order to provide a more general interface to support complex energy and specie
transport models, in particular multi-component diffusion. Currently only the
Fourier for laminar and eddyDiffusivity for RAS and LES turbulent flows are
provided but the interface is general and the set of models will be expanded in
the near future.
The ThermalDiffusivity and EddyDiffusivity modelling layers remain in
compressibleTurbulenceModels but will be removed shortly and the alphat boundary
conditions will be moved to ThermophysicalTransportModels.
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.
renaming the legacy keywords
RASModel -> model
LESModel -> model
laminarModel -> model
which is simpler and clear within the context in which they are specified, e.g.
RAS
{
model kOmegaSST;
turbulence on;
printCoeffs on;
}
rather than
RAS
{
RASModel kOmegaSST;
turbulence on;
printCoeffs on;
}
The old keywords are supported for backward compatibility.
This significant improvement is flexibility of SemiImplicitSource required a
generalisation of the source specification syntax and all tutorials have been
updated accordingly.
Description
Semi-implicit source, described using an input dictionary. The injection
rate coefficients are specified as pairs of Su-Sp coefficients, i.e.
\f[
S(x) = S_u + S_p x
\f]
where
\vartable
S(x) | net source for field 'x'
S_u | explicit source contribution
S_p | linearised implicit contribution
\endvartable
Example tabulated heat source specification for internal energy:
\verbatim
volumeMode absolute; // specific
sources
{
e
{
explicit table ((0 0) (1.5 $power));
implicit 0;
}
}
\endverbatim
Example coded heat source specification for enthalpy:
\verbatim
volumeMode absolute; // specific
sources
{
h
{
explicit
{
type coded;
name heatInjection;
code
#{
// Power amplitude
const scalar powerAmplitude = 1000;
// x is the current time
return mag(powerAmplitude*sin(x));
#};
}
implicit 0;
}
}
\endverbatim
The closeness option in surfaceFeatures set in surfaceFeaturesDict, e.g.
closeness
{
// Output the closeness of surface points to other surface elements.
pointCloseness yes;
}
calculates and writes both the internal and external surface "closeness"
measures either of which could be used to set the span refinement in
snappyHexMesh depending on which side of the surface is being meshed which is
specified with either refinement mode "insideSpan" or "externalSpan", e.g. in
the tutorials/mesh/snappyHexMesh/pipe case the inside of the pipe is meshed and
refined based on the internal span using the following specification:
refinementRegions
{
pipeWall
{
mode insideSpan;
levels ((1000 2));
cellsAcrossSpan 40;
}
}
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;
}
Description
PTT model for viscoelasticity using the upper-convected time
derivative of the stress tensor with support for multiple modes.
Reference:
\verbatim
Thien, N. P., & Tanner, R. I. (1977).
A new constitutive equation derived from network theory.
Journal of Non-Newtonian Fluid Mechanics, 2(4), 353-365.
\endverbatim
Currently the common exponential form of the PTT model is provided but it could
easily be extended to also support the linear and quadratic forms if the need
arises.
The \ continuation line marker is no longer required, multi-line argument lists
are parsed naturally by searching for the end ), e.g. in
tutorials/multiphase/reactingTwoPhaseEulerFoam/laminar/titaniaSynthesis/system/controlDict
#includeFunc writeObjects \
( \
d.particles, \
phaseTransfer:dmidtf.TiO2.particlesAndVapor \
)
is now written in the simpler form:
#includeFunc writeObjects
(
d.particles,
phaseTransfer:dmidtf.TiO2.particlesAndVapor
)
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.
By specifying a list of coefficients in turbulenceProperties, e.g. for the
generalised Maxwell model:
modes
(
{
lambda 0.01;
}
{
lambda 0.04;
}
);
of for the generalised Giesekus model:
modes
(
{
lambda 0.01;
alphaG 0.05;
}
{
lambda 0.04;
alphaG 0.2;
}
);
Visco-elasticity stress tensors (sigma0, sigma1...) are solved for each mode and
summed to create the effective stress of the complex fluid:
Any number of modes can be specified and if only one mode is required the
'modes' entry is not read and the coefficients are obtained as before.
The mode sigma? fields are read if present otherwise are constructed and
initialised from the sigma field but all of the mode sigma? fields are written
for restart and the sigma field contains the sum.
References:
http://en.wikipedia.org/wiki/Generalized_Maxwell_model
Wiechert, E. (1889). Ueber elastische Nachwirkung.
(Doctoral dissertation, Hartungsche buchdr.).
Wiechert, E. (1893).
Gesetze der elastischen Nachwirkung für constante Temperatur.
Annalen der Physik, 286(11), 546-570.
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 hRefConst and eRefConst thermos that were local to
reacting*EulerFoam have been removed and the reference state that they
used has been incorporated into the standard hConst and eConst thermos.
The hConst thermo model now evaluates the enthalpy like so:
Ha = Hf + Hs
= Hf + Cp*(T - Tref) + Hsref (+ equation of state terms)
Where Ha is absolute enthalpy, Hs is sensible enthalpy, Cp is specific
heat at constant pressure, T is temperature, Tref is a reference
temperature and Hsref is a reference sensible enthalpy. Hf, Cp, Tref and
Hsref are user inputs. Of these, Tref and Hsref are new. An example
specification is as follows:
thermodynamics
{
Hf -1.34229e+07;
Cp 2078.4;
Tref 372.76;
Hsref 128652;
}
The ref quantities allows the user to specify a state around which to
linearise the relationship between temperature and enthalpy. This is
useful if the temperature range of the simulation is small enough to
consider the relationship linear, but linearity does not hold all the
way to standard conditions.
To maintain backwards compatibility, Tref defaults to standard
temperature, and Hsref defaults to zero, so a case using hConst thermo
requires no modification as a result of this change.
The only change to the default operation is that to calculate sensible
enthalpy Cp is multiplied by the difference between the current
temperature and the standard temperature, whether as previously Cp was
multiplied by the current temperature only. This means that at standard
conditions sensible enthalpy is now zero, and absolute enthalpy equals
the formation enthalpy. This is more consistent with the definitions of
the various enthalpies, and with other thermo models such as janaf. This
change should only affect reacting cases that use constant thermo
models.
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.
This case is an updated version of
tutorials/multiphase/multiphaseEulerFoam/damBreak4phase using the latest models
available in reactingMultiphaseEulerFoam for interface capturing.
In multiphase systems it is only necessary to solve for all but one of the
moving phases. The new referencePhase option allows the user to specify which
of the moving phases should not be solved, e.g. in constant/phaseProperties of the
tutorials/multiphase/reactingMultiphaseEulerFoam/RAS/fluidisedBed tutorial case with
phases (particles air);
referencePhase air;
the particles phase is solved for and the air phase fraction and fluxes obtained
from the particles phase which provides equivalent behaviour to
reactingTwoPhaseEulerFoam and is more efficient than solving for both phases.
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.
e.g. in tutorials/incompressible/pisoFoam/LES/motorBike/motorBike/system/cuttingPlane
surfaceFormat vtk;
writeFormat binary;
fields (p U);
selects writing the VTK surface files in binary format which significantly
speeds-up reading of the files in paraview.
Currently binary writing is supported in VTK and EnSight formats.
In the new tutorial mesh/snappyHexMesh/pipe the pipe diameter changes by a factor
of 2 but the number of cells across the pipe is specified to be constant along
the length using the new "span" refinement mode in which the number of cells
across the span is set to be at least 40:
refinementRegions
{
pipe
{
mode span;
levels ((1000 2)); // Maximum distance and maximum level
cellsAcrossSpan 40;
}
}
This operates in conjunction with the "pointCloseness" option in surfaceFeatures
which writes a surfacePointScalarField of the local span of the domain. Note
that the behaviour of this option is critically dependent on the quality of this
field and the surface may need to be re-triangulated more isotropically to
ensure the "pointCloseness" is accurate and representative of the domain and the
required mesh distribution.
The calculation and input/output of transformations has been rewritten
for all coupled patches. This replaces multiple duplicated, inconsistent
and incomplete implementations of transformation handling which were
spread across the different coupled patch types.
Transformations are now calculated or specified once, typically during
mesh construction or manipulation, and are written out with the boundary
data. They are never re-calculated. Mesh changes should not change the
transformation across a coupled interface; to do so would violate the
transformation.
Transformations are now calculated using integral properties of the
patches. This is more numerically stable that the previous methods which
functioned in terms of individual faces. The new routines are also able
to automatically calculate non-zero centres of rotation.
The user input of transformations is backwards compatible, and permits
the user to manually specify varying amounts of the transformation
geometry. Anything left unspecified gets automatically computed from the
patch geometry. Supported specifications are:
1) No specification. Transformations on cyclics are automatically
generated, and cyclicAMI-type patches assume no transformation. For
example (in system/blockMeshDict):
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
faces ((4 5 6 7));
}
2) Partial specification. The type of transformation is specified
by the user, as well as the coordinate system if the transform is
rotational. The rotation angle or separation vector is still
automatically generated. This form is useful as the signs of the
angle and separation are opposite on different sides of an interface
and can be difficult to specify correctly. For example:
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
transformType translational;
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
transformType translational;
faces ((4 5 6 7));
}
cyclicAMILeft
{
type cyclicAMI;
neighbourPatch cyclicAMIRight;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
faces ((8 9 10 11));
}
cyclicAMIRight
{
type cyclicAMI;
neighbourPatch cyclicAMILeft;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
faces ((12 13 14 15));
}
3) Full specification. All parameters of the transformation are
given. For example:
cyclicLeft
{
type cyclic;
neighbourPatch cyclicRight;
transformType translational;
separaion (-0.01 0 0);
faces ((0 1 2 3));
}
cyclicRight
{
type cyclic;
neighbourPatch cyclicLeft;
transformType translational;
separaion (0.01 0 0);
faces ((4 5 6 7));
}
cyclicAMILeft
{
type cyclicAMI;
neighbourPatch cyclicAMIRight;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
rotationAngle 60;
faces ((8 9 10 11));
}
cyclicAMIRight
{
type cyclicAMI;
neighbourPatch cyclicAMILeft;
transformType rotational;
rotationAxis (0 0 1);
rotationCentre (0.05 -0.01 0);
rotationAngle 60;
faces ((12 13 14 15));
}
Automatic ordering of faces and points across coupled patches has also
been rewritten, again replacing multiple unsatisfactory implementations.
The new ordering method is more robust on poor meshes as it
geometrically matches only a single face (per contiguous region of the
patch) in order to perform the ordering, and this face is chosen to be
the one with the highest quality. A failure in ordering now only occurs
if the best face in the patch cannot be geometrically matched, whether
as previously the worst face could cause the algorithm to fail.
The oldCyclicPolyPatch has been removed, and the mesh converters which
previously used it now all generate ordered cyclic and baffle patches
directly. This removes the need to run foamUpgradeCyclics after
conversion. In addition the fluent3DMeshToFoam converter now supports
conversion of periodic/shadow pairs to OpenFOAM cyclic patches.
