The themo tables used in wallBoiling have had their Cp/Cv values
corrected, and have been coarsened and reduced in size to bound only the
operating point of the wallBoiling tutorials. They have also been moved
to $FOAM_TUTORIALS/resources/thermoData.
The correction to thermophysical properties has improved the stability
of these cases. As a result it has been possible to reduce the amount of
under-relaxation used in the wall modelling.
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 thermo parcel now supports thermophysical property modelling. This
particle does not store phase or specie fractions so it only provides a
single phase with a uniform composition. Additional specification is
required in the cloud subModel configuration in order to select the
specie. For example:
compositionModel singlePhaseMixture;
singlePhaseMixtureCoeffs
{
phases
(
solid
{
CaCO3 1;
}
);
}
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
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.
Properties have been removed that are set in the standard TDAC ".cfg"
file, and ".orig" files have been used to better ensure that cleanCase
restores the original state. Sandia has also had it's TDAC parameters
slightly tweaked for stability.
The "initialSet" and "fuelSpecies" settings for chemistry reduction
methods now have to be formatted as lists, rather than dictionaries.
This is so that the settings in the TDAC configuration files can be
overridden in a case without the dictionaries being merged.
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
so that they operate in the conventional manner in a right-handed coordinate
system:
//- Rotational transformation tensor about the x-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rx(const scalar& omega)
//- Rotational transformation tensor about the y-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ry(const scalar& omega)
//- Rotational transformation tensor about the z-axis by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Rz(const scalar& omega)
//- Rotational transformation tensor about axis a by omega radians
// The rotation is defined in a right-handed coordinate system
// i.e. clockwise with respect to the axis from -ve to +ve
// (looking along the axis).
inline tensor Ra(const vector& a, const scalar omega)
Description
Transform (translate, rotate, scale) a surface.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Supported transformations:
- \par translate=<translation vector>
Translational transformation by given vector
- \par rotate=(\<n1 vector\> \<n2 vector\>)
Rotational transformation from unit vector n1 to n2
- \par Rx=\<angle [deg] about x-axis\>
Rotational transformation by given angle about x-axis
- \par Ry=\<angle [deg] about y-axis\>
Rotational transformation by given angle about y-axis
- \par Rz=\<angle [deg] about z-axis\>
Rotational transformation by given angle about z-axis
- \par Ra=\<axis vector\> \<angle [deg] about axis\>
Rotational transformation by given angle about given axis
- \par scale=\<x-y-z scaling vector\>
Anisotropic scaling by the given vector in the x, y, z
coordinate directions
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
Ry=3.485, \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
The transformation sequence is specified like a substitution string used by
Description
Transform (translate, rotate, scale) a surface.
The rollPitchYaw option takes three angles (degrees):
- roll (rotation about x) followed by
- pitch (rotation about y) followed by
- yaw (rotation about z)
The yawPitchRoll does yaw followed by pitch followed by roll.
Usage
\b surfaceTransformPoints "\<transformations\>" \<input\> \<output\>
Example usage:
surfaceTransformPoints \
"translate=(-0.586 0 -0.156), \
rollPitchYaw=(0 -3.485 0), \
translate=(0.586 0 0.156)" \
constant/geometry/w3_orig.stl constant/geometry/w3.stl
Assuming the heat required to cause the phase change is provided by the film the
energy transferred with the mass to the primary region corresponds to vapour
at the film surface temperature.
The constant heat capacity hacked thermo in surfaceFilmModels and the
corresponding transfer terms in Lagrangian have been replaced by the standard
OpenFOAM rhoThermo which provides a general handling of thermo-physical
properties, in particular non-constant heat capacity. Further rationalisation
of liquid and solid properties has also been undertaken in support of this work
to provide a completely consistent interface to sensible and absolute enthalpy.
Now for surfaceFilmModels the thermo-physical model and properties are specified
in a constant/<region>/thermophysicalProperties dictionary consistent with all
other types of continuum simulation.
This significantly rationalises, simplifies and generalises the handling of
thermo-physical properties for film simulations and is a start at doing the same
for Lagrangian.
This model applies a heat source. It requires either the power, Q, or
the power per unit volume, q, to be specified.
Example usage:
heatSource
{
type heatSource;
selectionMode cellSet;
cellSet heater;
Q 1e6;
}
There is now just one inter-region heat transfer model, and heat
transfer coefficient models are selected as sub-models. This has been
done to permit usage of the heat transfer models in other contexts.
Example usage:
interRegionHeatTransfer
{
type interRegionHeatTransfer;
interRegionHeatTransferCoeffs
{
nbrRegion other;
interpolationMethod cellVolumeWeight;
master true;
semiImplicit no;
type constant;
AoV 200;
htc 10;
}
}
pMin and pMax settings are now available in multiphaseEulerFoam in the
PIMPLE section of the system/fvOptions file. This is consistent with
other compressible solvers. The pMin setting in system/phaseProperties
is no longer read, and it's presence will result in a warning.
SLGThermo has been moved to lagrangian, which still depends on it, pending
complete removal and replacement with a more rational interface to the carrier
phase thermodynamics.
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 population balance suffix after the phase suffix makes determining the
phase for a given name more complex. The additional suffix is also
unnecessary as a phase can only ever belong to one population balance,
so the phase name alone uniquely idetifies the grouping.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
Specifying a plane with which to subset feature edges is now done using
the same dictionary syntax used elsewhere in OpenFOAM. For example, in
system/surfaceFeaturesDict:
subsetFeatures
{
// Include only edges that intersect the plane
plane
{
planeType pointAndNormal;
point (0 0 0);
normal (1 0 0);
}
...
}
