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.
Some tutorials have had Allrun scripts added in order to run setFields,
which was previously omitted. Others have had nonuniform field files in
the 0 directory replaced by uniform files with .orig extensions.
These BCs blend between typical inflow and outflow conditions based on the
velocity orientation.
airFoil2D tutorial updated to demonstrate these new BCs.
Without -fields specified mergeOrSplitBaffles now manipulates the mesh only and
with the -fields option also updates the fields corresponding to the mesh change.
Now if a <field> file does not exist first the compressed <field>.gz file is
searched for and if that also does not exist the <field>.orig file is searched
for.
This simplifies case setup and run scripts as now setField for example can read
the <field>.orig file directly and generate the <field> file from it which is
then read by the solver. Additionally the cleanCase function used by
foamCleanCase and the Allclean scripts automatically removed <field> files if
there is a corresponding <field>.orig file. So now there is no need for the
Allrun scripts to copy <field>.orig files into <field> or for the Allclean
scripts to explicitly remove them.
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;
