To switch-off radiation set
radiationModel none;
in radiationProperties which instantiates "null" model that does not read any
data or coefficients or evaluate any fields.
The sampled sets have been renamed in a more explicit and consistent
manner, and two new ones have also been added. The available sets are as
follows:
arcUniform: Uniform samples along an arc. Replaces "circle", and
adds the ability to sample along only a part of the circle's
circumference. Example:
{
type arcUniform;
centre (0.95 0 0.25);
normal (1 0 0);
radial (0 0 0.25);
startAngle -1.57079633;
endAngle 0.52359878;
nPoints 200;
axis x;
}
boundaryPoints: Specified point samples associated with a subset of
the boundary. Replaces "patchCloud". Example:
{
type boundaryPoints;
patches (inlet1 inlet2);
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
maxDistance 0.01;
axis x;
}
boundaryRandom: Random samples within a subset of the boundary.
Replaces "patchSeed", but changes the behaviour to be entirely
random. It does not seed the boundary face centres first. Example:
{
type boundaryRandom;
patches (inlet1 inlet2);
nPoints 1000;
axis x;
}
boxUniform: Uniform grid of samples within a axis-aligned box.
Replaces "array". Example:
{
type boxUniform;
box (0.95 0 0.25) (1.2 0.25 0.5);
nPoints (2 4 6);
axis x;
}
circleRandom: Random samples within a circle. New. Example:
{
type circleRandom;
centre (0.95 0 0.25);
normal (1 0 0);
radius 0.25;
nPoints 200;
axis x;
}
lineFace: Face-intersections along a line. Replaces "face". Example:
{
type lineFace;
start (0.6 0.6 0.5);
end (0.6 -0.3 -0.1);
axis x;
}
lineCell: Cell-samples along a line at the mid-points in-between
face-intersections. Replaces "midPoint". Example:
{
type lineCell;
start (0.5 0.6 0.5);
end (0.5 -0.3 -0.1);
axis x;
}
lineCellFace: Combination of "lineFace" and "lineCell". Replaces
"midPointAndFace". Example:
{
type lineCellFace;
start (0.55 0.6 0.5);
end (0.55 -0.3 -0.1);
axis x;
}
lineUniform: Uniform samples along a line. Replaces "uniform".
Example:
{
type lineUniform;
start (0.65 0.3 0.3);
end (0.65 -0.3 -0.1);
nPoints 200;
axis x;
}
points: Specified points. Replaces "cloud" when the ordered flag is
false, and "polyLine" when the ordered flag is true. Example:
{
type points;
points ((0 -0.05 0.05) (0 -0.05 0.1) (0 -0.05 0.15));
ordered yes;
axis x;
}
sphereRandom: Random samples within a sphere. New. Example:
{
type sphereRandom;
centre (0.95 0 0.25);
radius 0.25;
nPoints 200;
axis x;
}
triSurfaceMesh: Samples from all the points of a triSurfaceMesh.
Replaces "triSurfaceMeshPointSet". Example:
{
type triSurfaceMesh;
surface "surface.stl";
axis x;
}
The headers have also had documentation added. Example usage and a
description of the control parameters now exists for all sets.
In addition, a number of the algorithms which generate the sets have
been refactored or rewritten. This was done either to take advantage of
the recent changes to random number generation, or to remove ad-hoc
fixes that were made unnecessary by the barycentric tracking algorithm.
The template is designed to work with the new foamSetupCHT utility.
It works simply for cases with a single fluid region (and multiple
solid regions); it can also be adapted for cases with multiple fluid
regions. For more information see the included README file.
snappyHexMesh produces a far better quality AMI interface using a cylindrical background mesh,
leading to much more robust performance, even on a relatively coarse mesh. The min/max AMI
weights remain close to 1 as the mesh moves, giving better conservation.
The rotating geometry template cases are configured with a blockMeshDict file for a cylindrical
background mesh aligned along the z-axis. The details of use are found in the README and
blockMeshDict files.
Uncommenting the patches provides a convenient way to use the patches in the background mesh
to define the external boundary of the final mesh. Replaces previous setup with a separate
blockMeshDict.extPatches file.
rhoSimpleFoam now instantiates the lower-level fluidThermo which instantiates
either a psiThermo or rhoThermo according to the 'type' specification in
thermophysicalProperties, e.g.
thermoType
{
type hePsiThermo;
mixture pureMixture;
transport sutherland;
thermo janaf;
equationOfState perfectGas;
specie specie;
energy sensibleInternalEnergy;
}
instantiates a psiThermo for a perfect gas with JANAF thermodynamics, whereas
thermoType
{
type heRhoThermo;
mixture pureMixture;
properties liquid;
energy sensibleInternalEnergy;
}
mixture
{
H2O;
}
instantiates a rhoThermo for water, see new tutorial
compressible/rhoSimpleFoam/squareBendLiq.
In order to support complex equations of state the pressure can no longer be
unlimited and rhoSimpleFoam now limits the pressure rather than the density to
handle start-up more robustly.
For backward compatibility 'rhoMin' and 'rhoMax' can still be used in the SIMPLE
sub-dictionary of fvSolution which are converted into 'pMax' and 'pMin' but it
is better to set either 'pMax' and 'pMin' directly or use the more convenient
'pMinFactor' and 'pMinFactor' from which 'pMax' and 'pMin' are calculated using
the fixed boundary pressure or reference pressure e.g.
SIMPLE
{
nNonOrthogonalCorrectors 0;
pMinFactor 0.1;
pMaxFactor 1.5;
transonic yes;
consistent yes;
residualControl
{
p 1e-3;
U 1e-4;
e 1e-3;
"(k|epsilon|omega)" 1e-3;
}
}
The fundamental properties provided by the specie class hierarchy were
mole-based, i.e. provide the properties per mole whereas the fundamental
properties provided by the liquidProperties and solidProperties classes are
mass-based, i.e. per unit mass. This inconsistency made it impossible to
instantiate the thermodynamics packages (rhoThermo, psiThermo) used by the FV
transport solvers on liquidProperties. In order to combine VoF with film and/or
Lagrangian models it is essential that the physical propertied of the three
representations of the liquid are consistent which means that it is necessary to
instantiate the thermodynamics packages on liquidProperties. This requires
either liquidProperties to be rewritten mole-based or the specie classes to be
rewritten mass-based. Given that most of OpenFOAM solvers operate
mass-based (solve for mass-fractions and provide mass-fractions to sub-models it
is more consistent and efficient if the low-level thermodynamics is also
mass-based.
This commit includes all of the changes necessary for all of the thermodynamics
in OpenFOAM to operate mass-based and supports the instantiation of
thermodynamics packages on liquidProperties.
Note that most users, developers and contributors to OpenFOAM will not notice
any difference in the operation of the code except that the confusing
nMoles 1;
entries in the thermophysicalProperties files are no longer needed or used and
have been removed in this commet. The only substantial change to the internals
is that species thermodynamics are now "mixed" with mass rather than mole
fractions. This is more convenient except for defining reaction equilibrium
thermodynamics for which the molar rather than mass composition is usually know.
The consequence of this can be seen in the adiabaticFlameT, equilibriumCO and
equilibriumFlameT utilities in which the species thermodynamics are
pre-multiplied by their molecular mass to effectively convert them to mole-basis
to simplify the definition of the reaction equilibrium thermodynamics, e.g. in
equilibriumCO
// Reactants (mole-based)
thermo FUEL(thermoData.subDict(fuelName)); FUEL *= FUEL.W();
// Oxidant (mole-based)
thermo O2(thermoData.subDict("O2")); O2 *= O2.W();
thermo N2(thermoData.subDict("N2")); N2 *= N2.W();
// Intermediates (mole-based)
thermo H2(thermoData.subDict("H2")); H2 *= H2.W();
// Products (mole-based)
thermo CO2(thermoData.subDict("CO2")); CO2 *= CO2.W();
thermo H2O(thermoData.subDict("H2O")); H2O *= H2O.W();
thermo CO(thermoData.subDict("CO")); CO *= CO.W();
// Product dissociation reactions
thermo CO2BreakUp
(
CO2 == CO + 0.5*O2
);
thermo H2OBreakUp
(
H2O == H2 + 0.5*O2
);
Please report any problems with this substantial but necessary rewrite of the
thermodynamic at https://bugs.openfoam.org
Henry G. Weller
CFD Direct Ltd.
This changes simplifies the specification of functionObjects in
controlDict and is consistent with the 'libs' option in controlDict to
load special solver libraries.
Support for the old 'functionObjectLibs' name is supported for backward compatibility.
to have the prefix 'write' rather than 'output'
So outputTime() -> writeTime()
but 'outputTime()' is still supported for backward-compatibility.
Also removed the redundant secondary-writing functionality from Time
which has been superseded by the 'writeRegisteredObject' functionObject.
for consistency with the time controls in controlDict and to avoid
unnecessary confusion. All code and tutorials have been updated.
The old names 'outputControl' and 'outputInterval' are but supported for
backward compatibility but deprecated.
so that the specification of the name and dimensions are optional in property dictionaries.
Update tutorials so that the name of the dimensionedScalar property is
no longer duplicated but optional dimensions are still provided and are
checked on read.
The templates include a stategy to simplify meshing with snappyHexMesh,
particularly to help generate an initial mesh quickly that can subsequently be
improved. The templates are setup to enable rapid initial simulations, typically
with simpleFoam. The initial templates cover simple inflow-outflow and closed
domains, including rotating geometry, and an example axisymmetric flow. For
more details, consult the README file accompanying each template case.
The cases are located in $FOAM_ETC/templates