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.
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)"
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.
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.
A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
Originally the only supported geometry specification were triangulated surfaces,
hence the name of the directory: constant/triSurface, however now that other
surface specifications are supported and provided it is much more logical that
the directory is named accordingly: constant/geometry. All tutorial and
template cases have been updated.
Note that backward compatibility is provided such that if the constant/geometry
directory does not exist but constant/triSurface does then the geometry files
are read from there.
It is better to not select and instantiate a model, fvOption etc. than to create
it and set it inactive as the creation process requires reading of settings,
parameters, fields etc. with all the associated specification and storage
without being used. Also the incomplete implementation added a lot of
complexity in the low-level operation of models introducing a significant
maintenance overhead and development overhead for new models.
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.
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.
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.
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.
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)
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;
}
);
}
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.
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.
A surface geometry file should be stored in
$FOAM_TUTORIALS/resources/geometry if it is used in multiple cases,
otherwise it should be stored locally to the case. This change enforces
that across all tutorials.
Rather than defining patches for all external block faces to provide name and
type use the defaultPatch entry to collect undefined faces into a single named
and typed patch, e.g.
defaultPatch
{
name walls;
type wall;
}
Description
Reciprocal polynomial equation of state for liquids and solids
\f[
1/\rho = C_0 + C_1 T + C_2 T^2 - C_3 p - C_4 p T
\f]
This polynomial for the reciprocal of the density provides a much better fit
than the equivalent polynomial for the density and has the advantage that it
support coefficient mixing to support liquid and solid mixtures in an
efficient manner.
Usage
\table
Property | Description
C | Density polynomial coefficients
\endtable
Example of the specification of the equation of state for pure water:
\verbatim
equationOfState
{
C (0.001278 -2.1055e-06 3.9689e-09 4.3772e-13 -2.0225e-16);
}
\endverbatim
Note: This fit is based on the small amount of data which is freely
available for the range 20-65degC and 1-100bar.
This equation of state is a much better fit for water and other liquids than
perfectFluid and in general polynomials for the reciprocal of the density
converge much faster than polynomials of the density. Currently rPolynomial is
quadratic in the temperature and linear in the pressure which is sufficient for
modest ranges of pressure typically encountered in CFD but could be extended to
higher order in pressure and/temperature if necessary. The other huge advantage
in formulating the equation of state in terms of the reciprocal of the density
is that coefficient mixing is simple.
Given these advantages over the perfectFluid equation of state the libraries and
tutorial cases have all been updated to us rPolynomial rather than perfectFluid
for liquids and water in particular.
The volumeFractionSource represents the effect of a reduction in the
volume of the domain due to the presence of a stationary phase, most
likely a solid porous media. It only represents the dynamic effects
associated with the reduction in volume; it does not does not model
loss, drag or heat transfer. Separate models (e.g., the existing
porosity models) will be necessary to represent these effects. An
example usage, in system/fvOptions, is as follows:
volumeFraction
{
type volumeFractionSource;
phase solid;
phi phi;
rho rho;
U U;
fields (rho U e);
}
The volume fraction will be read from constant/alpha.<phase>, and must
be generated in advance using setFields or a function object. Note that
the names of the flux, density (if compressible) and velocity must all
be specified. Every field for which a transport equation is solved
should also be specified in the "fields" entry.
The solidEquilibriumEnergySource adds the thermal inertia and diffusive
characteristics of a stationary solid phase to the energy equation of
the fluid, assuming that the two phases are in thermal equilibrium. An
example usage is as follows:
solidEqulibriumEnergy
{
type solidEqulibriumEnergySource;
phase solid;
field e;
}
This will read the volume fraction in the same way as the
volumeFractionSource option. In addition, thermal properties of the
solid will be constructed from settings in
system/thermophysicalProperties.<phase>.
Two tutorials have been added, demonstrating use of these options in
both incompressible and compressible simulations. These are
incompressible/pimpleFoam/laminar/blockedChannel and
compressible/rhoPimpleFoam/laminar/blockedChannel.
Now for transient simulations "Final" solver settings are required for ALL
equations providing consistency between the solution of velocity, energy,
composition and radiation properties.
However "Final" relaxation factors are no longer required for fields or
equations and if not present the standard value for the variable will be
applied. Given that relaxation factors other than 1 are rarely required for
transient runs and hence the same for all iterations including the final one
this approach provide simpler input while still providing the flexibility to
specify a different value for the final iteration if required. For steady cases
it is usual to execute just 1 outer iteration per time-step for which the
standard relaxation factors are appropriate, and if more than one iteration is
executed it is common to use the same factors for both. In the unlikely event
of requiring different relaxation factors for the final iteration this is still
possible to specify via the now optional "Final" specification.
to avoid the need to evaluate departure functions and simplify evaluation of the
temperature. In general it makes more sense to use and e/Cv based
thermodynamics when solving for internal energy rather than h/Cp and have
convert between the energy forms.
All related tutorials and test cases have also been updated.
