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.
Surfaces are specified as a list and the controls applied to each, e.g. in the
rhoPimpleFoam/RAS/annularThermalMixer tutorial:
surfaces
(
"AMI.obj"
"shaft.obj"
"wall.obj"
"statorBlades.obj"
"rotorBlades.obj"
);
includedAngle 150; // Identifes a feature when angle
// between faces < includedAngle
trimFeatures
{
minElem 10; // minimum edges within a feature
}
writeObj yes; // writes out _edgeMesh.obj files to view features
If different controls are required for different surfaces multiple
sub-dictionaries can be used:
AMIsurfaces
{
surfaces
(
"AMI.obj"
);
includedAngle 140; // Identifes a feature when angle
// between faces < includedAngle
trimFeatures
{
minElem 8; // minimum edges within a feature
}
writeObj yes; // writes out _edgeMesh.obj files to view features
}
otherSurfaces
{
surfaces
(
"shaft.obj"
"wall.obj"
"statorBlades.obj"
"rotorBlades.obj"
);
includedAngle 150; // Identifes a feature when angle
// between faces < includedAngle
trimFeatures
{
minElem 10; // minimum edges within a feature
}
writeObj yes; // writes out _edgeMesh.obj files to view features
}
Existing feature edge files corresponding to particular surfaces can be specified using
the "files" association list:
surfaces
(
"AMI.obj"
"shaft.obj"
"wall.obj"
"statorBlades.obj"
"rotorBlades.obj"
);
files
(
"AMI.obj" "constant/triSurface/AMI.obj.eMesh";
);
includedAngle 150; // Identifes a feature when angle
// between faces < includedAngle
trimFeatures
{
minElem 10; // minimum edges within a feature
}
writeObj yes; // writes out _edgeMesh.obj files to view features
The tutorial demonstrates generation of a C-grid mesh using blockMesh
The geometry is provided by a surface mesh (OBJ file) of the NACA0012 aerofoil
The case is setup with a freestream flow speed of Ma=0.72
Thanks to Kai Bastos at Duke University for the geometry and helpful input.
The solution controls have been rewritten for use in multi-region
solvers, and PIMPLE fluid/solid solution controls have been implemented
within this framework.
PIMPLE also now has time-loop convergence control which can be used to
end the simulation once a certain initial residual is reached. This
allows a PIMPLE solver to run with equivalent convergence control to a
SIMPLE solver. Corrector loop convergence control is still available,
and can be used at the same time as the time-loop control.
The "residualControl" sub-dictionary of PIMPLE contains the residual
values required on the first solve of a time-step for the simulation to
end. This behaviour is the same as SIMPLE. The
"outerCorrectorResidualControl" sub-dictionary contains the tolerances
required for the corrector loop to exit. An example specification with
both types of control active is shown below.
PIMPLE
{
// ...
residualControl
{
p 1e-3;
U 1e-4;
"(k|epsilon|omega)" 1e-3;
}
outerCorrectorResidualControl
{
U
{
tolerance 1e-4;
relTol 0.1;
}
"(k|epsilon|omega)"
{
tolerance 1e-3;
relTol 0.1;
}
}
}
Note that existing PIMPLE "residualControl" entries will need to be
renamed "outerCorrectorResidualControl".
Application within a solver has also changed slightly. In order to have
convergence control for the time loop as a whole, the
solutionControl::loop(Time&) method (or the equivalent run method) must
be used; i.e.,
while (simple.loop(runTime))
{
Info<< "Time = " << runTime.timeName() << nl << endl;
// solve ...
}
or,
while (pimple.run(runTime))
{
// pre-time-increment operations ...
runTime ++;
Info<< "Time = " << runTime.timeName() << nl << endl;
// solve ...
}
Using the noSlip boundary condition for rotating wall in an MRF region
interferes with post-processing by resetting the wall velocity to 0 rather than
preserving the value set by the MRF zone.
and replaced rhoPimpleDyMFoam with a script which reports this change.
The rhoPimpleDyMFoam tutorials have been moved into the rhoPimpleFoam directory.
This change is the first of a set of developments to merge dynamic mesh
functionality into the standard solvers to improve consistency, usability,
flexibility and maintainability of these solvers.
Henry G. Weller
CFD Direct Ltd.
and replaced pimpleDyMFoam with a script which reports this change.
The pimpleDyMFoam tutorials have been moved into the pimpleFoam directory.
This change is the first of a set of developments to merge dynamic mesh
functionality into the standard solvers to improve consistency, usability,
flexibility and maintainability of these solvers.
Henry G. Weller
CFD Direct Ltd.
See tutorials/compressible/rhoPimpleFoam/RAS/squareBendLiq for exapmle
pimpleControl: Added SIMPLErho option for running in SIMPLE mode
with large time-step/Courant number and relaxation. With this option the
density is updated from thermodynamics rather than continuity after the pressure
equation which is better behaved if pressure is relaxed and/or solved to a
loose relative tolerance. The need for this option is demonstrated in the
tutorials/compressible/rhoPimpleFoam/RAS/angledDuct tutorial which is unstable
without the option.
except turbulence and lagrangian which will also be updated shortly.
For example in the nonNewtonianIcoFoam offsetCylinder tutorial the viscosity
model coefficients may be specified in the corresponding "<type>Coeffs"
sub-dictionary:
transportModel CrossPowerLaw;
CrossPowerLawCoeffs
{
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
}
BirdCarreauCoeffs
{
nu0 [0 2 -1 0 0 0 0] 1e-06;
nuInf [0 2 -1 0 0 0 0] 1e-06;
k [0 0 1 0 0 0 0] 0;
n [0 0 0 0 0 0 0] 1;
}
which allows a quick change between models, or using the simpler
transportModel CrossPowerLaw;
nu0 [0 2 -1 0 0 0 0] 0.01;
nuInf [0 2 -1 0 0 0 0] 10;
m [0 0 1 0 0 0 0] 0.4;
n [0 0 0 0 0 0 0] 3;
if quick switching between models is not required.
To support this more convenient parameter specification the inconsistent
specification of seedSampleSet in the streamLine and wallBoundedStreamLine
functionObjects had to be corrected from
// Seeding method.
seedSampleSet uniform; //cloud; //triSurfaceMeshPointSet;
uniformCoeffs
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
to the simpler
// Seeding method.
seedSampleSet
{
type uniform;
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
which also support the "<type>Coeffs" form
// Seeding method.
seedSampleSet
{
type uniform;
uniformCoeffs
{
axis x; //distance;
// Note: tracks slightly offset so as not to be on a face
start (-1.001 -0.05 0.0011);
end (-1.001 -0.05 1.0011);
nPoints 20;
}
}
For example the porosity coefficients may now be specified thus:
porosity1
{
type DarcyForchheimer;
cellZone porosity;
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
rather than
porosity1
{
type DarcyForchheimer;
active yes;
cellZone porosity;
DarcyForchheimerCoeffs
{
d (5e7 -1000 -1000);
f (0 0 0);
coordinateSystem
{
type cartesian;
origin (0 0 0);
coordinateRotation
{
type axesRotation;
e1 (0.70710678 0.70710678 0);
e2 (0 0 1);
}
}
}
}
support for which is maintained for backward compatibility.
For example the actuationDiskSource fvOption may now be specified
disk1
{
type actuationDiskSource;
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
rather than
disk1
{
type actuationDiskSource;
active on;
actuationDiskSourceCoeffs
{
fields (U);
selectionMode cellSet;
cellSet actuationDisk1;
diskDir (1 0 0); // Orientation of the disk
Cp 0.386;
Ct 0.58;
diskArea 40;
upstreamPoint (581849 4785810 1065);
}
}
but this form is supported for backward compatibility.
The pitzDaily case uses a lot of mesh grading close to walls and the shear layer.
Prior to v2.4, blockMesh only permitted grading in one direction within a single block,
so the pitzDaily mesh comprised of 13 blocks to accommodate the complex grading pattern.
blockMesh has multi-grading that allows users to divide a block in a given direction and
apply different grading within each division. The mesh generated with blockMesh using
13 blocks has been replaced with a mesh of 5 blocks that use multi-grading. The new
blockMeshDict configuration produces a mesh very similar to the original 13-block mesh.
Both stardard SIMPLE and the SIMPLEC (using the 'consistent' option in
fvSolution) are now supported for both subsonic and transonic flow of all
fluid types.
rhoPimpleFoam now instantiates the lower-level fluidThermo which instantiates
either a psiThermo or rhoThermo according to the 'type' specification in
thermophysicalProperties, see also commit 655fc78748
Both stardard SIMPLE and the SIMPLEC (using the 'consistent' option in
fvSolution) are now supported for both subsonic and transonic flow of all
fluid types.
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.
e.g. the motion of two counter-rotating AMI regions could be defined:
dynamicFvMesh dynamicMotionSolverListFvMesh;
solvers
(
rotor1
{
solver solidBody;
cellZone rotor1;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
rotor2
{
solver solidBody;
cellZone rotor2;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega -6.2832; // rad/s
}
}
);
Any combination of motion solvers may be selected but there is no special
handling of motion interaction; the motions are applied sequentially and
potentially cumulatively.
To support this new general framework the solidBodyMotionFvMesh and
multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
corresponding motionSolvers solidBody and multiSolidBody and the tutorials
updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
is now defined thus:
dynamicFvMesh dynamicMotionSolverFvMesh;
solver solidBody;
solidBodyCoeffs
{
cellZone rotor;
solidBodyMotionFunction rotatingMotion;
rotatingMotionCoeffs
{
origin (0 0 0);
axis (0 0 1);
omega 6.2832; // rad/s
}
}
using a run-time selectable preconditioner
References:
Van der Vorst, H. A. (1992).
Bi-CGSTAB: A fast and smoothly converging variant of Bi-CG
for the solution of nonsymmetric linear systems.
SIAM Journal on scientific and Statistical Computing, 13(2), 631-644.
Barrett, R., Berry, M. W., Chan, T. F., Demmel, J., Donato, J.,
Dongarra, J., Eijkhout, V., Pozo, R., Romine, C. & Van der Vorst, H.
(1994).
Templates for the solution of linear systems:
building blocks for iterative methods
(Vol. 43). Siam.
See also: https://en.wikipedia.org/wiki/Biconjugate_gradient_stabilized_method
Tests have shown that PBiCGStab with the DILU preconditioner is more
robust, reliable and shows faster convergence (~2x) than PBiCG with
DILU, in particular in parallel where PBiCG occasionally diverges.
This remarkable improvement over PBiCG prompted the update of all
tutorial cases currently using PBiCG to use PBiCGStab instead. If any
issues arise with this update please report on Mantis: http://bugs.openfoam.org
Description
Constrain the field values within a specified region.
For example to set the turbulence properties within a porous region:
\verbatim
porosityTurbulence
{
type scalarFixedValueConstraint;
active yes;
scalarFixedValueConstraintCoeffs
{
selectionMode cellZone;
cellZone porosity;
fieldValues
{
k 30.7;
epsilon 1.5;
}
}
}
\endverbatim
See tutorials/compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff
constant/fvOptions for an example of this fvOption in action.
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
For most applications the totalPressure boundary condition now only
requires p0 to be specified e.g.
outlet
{
type totalPressure;
p0 uniform 1e5;
}
To re-use existing 'sampleDict' files simply add the following entries:
type sets;
libs ("libsampling.so");
and run
postProcess -func sampleDict
It is probably better to also rename 'sampleDict' -> 'sample' and then run
postProcess -func sampleDict
