This is a CHT case which uses snappyHexMesh. It is a tutorial, in the
traditional sense, in that it has been designed for training purposes.
It does not rely on changeDictionary, surface utilities, or extensive
scripting.
This work was supported by Colin Moughton, at Strix
A lower limit of one on the number of particles represented by a single
parcel has been removed from the injection models. It may be appropriate
to simulate the statistical behaviour of a particulate flow with more
lagrangian elements than physical particles. A unity lower limit does
not permit this.
The limit was, in some situations, also causing the large-diameter end
of an injected distribution to be clipped.
This resolves bug report https://bugs.openfoam.org/view.php?id=2837
The logic governing function objects' ability to change the time-step
has been modified so that it is compatible with the time-step adjustment
done in the Time class. The behaviour has been split into a method which
sets the step directly, and another which moidifies the time until the
next write operation (i.e., the time that the solver "aims" for).
This fixes an issue where the adjustments in Time and the function
objects interfere and cause the time step to decrease exponentially down
to machine precision. It also means that the set-time-step function
object now does not break the adjustable run-time setting.
This resolves bug report https://bugs.openfoam.org/view.php?id=2820
Splitting MPI_COMM_FOAM from MPI_COMM_WORLD allows OpenFOAM to be linked with
other libraries communicating via MPI.
Resolves feature request https://bugs.openfoam.org/view.php?id=2815
Multi-region PIMPLE controls have been applied to the chtMultiRegionFoam
solver, and a transonic option has been implemented.
The new PIMPLE controls let the solver operate SIMPLE mode. The
utilisation of library solution and convergence control functionality
has significantly reduced the amount of code in the solver. The
chtMultiRegionSimpleFoam solver has also been made obsolete, and has
therefore been removed.
A few changes will be necessary to convert an existing
chtMultiRegionSimpleFoam case to chtMultiRegionFoam. All the SIMPLE
sub-dictionaries in the system/<regions>/fvSolution will need to be
renamed PIMPLE. The system/fvSolution file will also need an empty
PIMPLE sub-dictionary. In addition, additional "<variable>Final" solver
and relaxation entries will be needed. For a steady case, adding a
wildcard ending, ".*", to the variable names should be sufficient.
Solution parameters appropriate for a steady case are shown below:
solvers
{
"p_rgh.*"
{
solver GAMG;
tolerance 1e-7;
relTol 0.01;
smoother DIC;
maxIter 10;
}
"(U|h|e|k|epsilon).*"
{
solver PBiCGStab;
preconditioner DILU;
tolerance 1e-7;
relTol 0.1;
}
}
PIMPLE
{
// ...
}
relaxationFactors
{
fields
{
"p_rgh.*" 0.7;
}
equations
{
"U.*" 0.5;
"(h|e).*" 0.3;
"(k|epsilon).*" 0.2;
}
}
This work was supported by Fabian Buelow, at Evonik
Tobias Holzmann provided cases for testing the convergence controls
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 ...
}
In constant/chemistryProperties in addition to the specification of the initial
ODE integration time-step used at the start of the run:
initialChemicalTimeStep 1e-12;
this time step may now also be specified for every chemistry integration by
setting the optional entry maxChemicalTimeStep, e.g.
maxChemicalTimeStep 1e-12;
OpenFOAM can now be compiled with single, double or long double scalars by
setting the WM_PRECISION_OPTION environment variable to either SP, DP or LP
respectively.
On most 64bit systems long double is stored as 128bit but computed in the
floating point hardware to 80bit. Due to the increased storage compared to
double precision cache and memory access is significantly more time consuming
causing a slow-down of floating point intensive operations by a factor of 2 to
3.
An unintended change in the running-state logic was introduced by commit
9a35ce69. The running state should only be re-evaluated when in the
simulation is not ending. The "execute/end" function object invocation
should not be permitted to change the running state. The simulation
should always end if this state is reached.
In early versions of OpenFOAM the scalar limits were simple macro replacements and the
names were capitalized to indicate this. The scalar limits are now static
constants which is a huge improvement on the use of macros and for consistency
the names have been changed to camel-case to indicate this and improve
readability of the code:
GREAT -> great
ROOTGREAT -> rootGreat
VGREAT -> vGreat
ROOTVGREAT -> rootVGreat
SMALL -> small
ROOTSMALL -> rootSmall
VSMALL -> vSmall
ROOTVSMALL -> rootVSmall
The original capitalized are still currently supported but their use is
deprecated.
Introduced thermalPhaseChangePopulationBalanceTwo- and MultiphaseSystem as
user-selectable phaseSystems which are the first to actually use multiple mass
transfer mechanisms enabled by
commit d3a237f560.
The functionality is demonstrated using the reactingTwoPhaseEulerFoam
wallBoilingPolydisperse tutorial.
Patch contributed by VTT Technical Research Centre of Finland Ltd and Institute
of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
and optionally the CPU and clock times per time step.
Example of function object specification:
time
{
type time;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
perTimeStep no;
}
Adding
#includeFunc time
to the functions list in the controlDict of the motorBike tutorial generates
0 1.190000e+00 1
1 1.640000e+00 1
2 1.940000e+00 2
Enabling the optional writing of the CPU and clock time per time step is
straight forward:
#includeFunc time(perTimeStep=yes)
With the writeJobInfo option in OpenFOAM-dev/etc/controlDict::InfoSwitches set
to 1 each OpenFOAM executable writes a <executable>.<pid> file containing the
job summary into the <case>/jobInfo directory, e.g. after running the
tutorials/incompressible/pisoFoam/RAS/cavity tutorials
tutorials/incompressible/pisoFoam/RAS/cavity/jobInfo contains
blockMesh.20169 pisoFoam.20170
