Two new phase models have been added as selectable options for
reactingMultiphaseEulerFoam; pureStationaryPhaseModel and
pureStationaryIsothermalPhaseModel. These phases do not store a
velocity and their phase fractions remain constant throughout the
simulation. They are intended for use in modelling static particle beds
and other forms of porous media by means of the existing Euler-Euler
transfer models (drag, heat transfer, etc...).
Note that this functionality has not been extended to
reactingTwoPhaseEulerFoam, or the non-reacting *EulerFoam solvers.
Additional maintenance work has been carried out on the phase model
and phase system structure. The system can now loop over subsets of
phases with specific functionality (moving, multi-component, etc...) in
order to avoid testing for the existence of equations or variables in
the top level solver. The mass transfer handling and it's effect on
per-phase source terms has been refactored to reduce duplication. Const
and non-const access to phase properties has been formalised by renaming
non-const accessors with a "Ref" suffix, which is consistent with other
recent developments to classes including tmp and GeometricField, among
others. More sub-modelling details have been made private in order to
reduce the size of interfaces and improve abstraction.
This work was supported by Zhen Li, at Evonik
MULES and CMULES have been extended so that the limits can be supplied
as fields. These arguments are templated so that zeroField, oneField or
UniformField<scalar> can be used in place of a scalar value with no
additional overhead. The flux argument has been removed from the
unlimited CMULES correct functions in order to make this templating
possible.
An additional form of limit sum has also been added to MULES. This
limits the flux sum by ofsetting in proportion to the phase fraction,
rather than by reducing the magnitude of the fluxes with the same sign
as the imbalance. The new procedure makes it possible to limit the flux
sum in the presence of constraints without encountering a divide by
zero.
Improvements to existing functionality
--------------------------------------
- MPI is initialised without thread support if it is not needed e.g. uncollated
- Use native c++11 threading; avoids problem with static destruction order.
- etc/cellModels now only read if needed.
- etc/controlDict can now be read from the environment variable FOAM_CONTROLDICT
- Uniform files (e.g. '0/uniform/time') are now read only once on the master only
(with the masterUncollated or collated file handlers)
- collated format writes to 'processorsNNN' instead of 'processors'. The file
format is unchanged.
- Thread buffer and file buffer size are no longer limited to 2Gb.
The global controlDict file contains parameters for file handling. Under some
circumstances, e.g. running in parallel on a system without NFS, the user may
need to set some parameters, e.g. fileHandler, before the global controlDict
file is read from file. To support this, OpenFOAM now allows the global
controlDict to be read as a string set to the FOAM_CONTROLDICT environment
variable.
The FOAM_CONTROLDICT environment variable can be set to the content the global
controlDict file, e.g. from a sh/bash shell:
export FOAM_CONTROLDICT=$(foamDictionary $FOAM_ETC/controlDict)
FOAM_CONTROLDICT can then be passed to mpirun using the -x option, e.g.:
mpirun -np 2 -x FOAM_CONTROLDICT simpleFoam -parallel
Note that while this avoids the need for NFS to read the OpenFOAM configuration
the executable still needs to load shared libraries which must either be copied
locally or available via NFS or equivalent.
New: Multiple IO ranks
----------------------
The masterUncollated and collated fileHandlers can now use multiple ranks for
writing e.g.:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)'
In this example ranks 0 ('processor0') and 3 ('processor3') now handle all the
I/O. Rank 0 handles 0,1,2 and rank 3 handles 3,4,5. The set of IO ranks should always
include 0 as first element and be sorted in increasing order.
The collated fileHandler uses the directory naming processorsNNN_XXX-YYY where
NNN is the total number of processors and XXX and YYY are first and last
processor in the rank, e.g. in above example the directories would be
processors6_0-2
processors6_3-5
and each of the collated files in these contains data of the local ranks
only. The same naming also applies when e.g. running decomposePar:
decomposePar -fileHandler collated -ioRanks '(0 3)'
New: Distributed data
---------------------
The individual root directories can be placed on different hosts with different
paths if necessary. In the current framework it is necessary to specify the
root per slave process but this has been simplified with the option of specifying
the root per host with the -hostRoots command line option:
mpirun -np 6 simpleFoam -parallel -ioRanks '(0 3)' \
-hostRoots '("machineA" "/tmp/" "machineB" "/tmp")'
The hostRoots option is followed by a list of machine name + root directory, the
machine name can contain regular expressions.
New: hostCollated
-----------------
The new hostCollated fileHandler automatically sets the 'ioRanks' according to
the host name with the lowest rank e.g. to run simpleFoam on 6 processors with
ranks 0-2 on machineA and ranks 3-5 on machineB with the machines specified in
the hostfile:
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler hostCollated
This is equivalent to
mpirun -np 6 --hostfile hostfile simpleFoam -parallel -fileHandler collated -ioRanks '(0 3)'
This example will write directories:
processors6_0-2/
processors6_3-5/
A typical example would use distributed data e.g. no two nodes, machineA and
machineB, each with three processes:
decomposePar -fileHandler collated -case cavity
# Copy case (constant/*, system/*, processors6/) to master:
rsync -a cavity machineA:/tmp/
# Create root on slave:
ssh machineB mkdir -p /tmp/cavity
# Run
mpirun --hostfile hostfile icoFoam \
-case /tmp/cavity -parallel -fileHandler hostCollated \
-hostRoots '("machineA" "/tmp" "machineB" "/tmp")'
Contributed by Mattijs Janssens
Partial elimination has been implemented for the multiphase Euler-Euler
solver. This does a linear solution of the drag system when calculating
flux and velocity corrections after the solution of the pressure
equation. This can improve the behaviour of the solution in the event
that the drag coupling is high. It is controlled by means of a
"partialElimination" switch within the PIMPLE control dictionary in
fvSolution.
A re-organisation has also been done in order to remove the exposure of
the sub-modelling from the top-level solver. Rather than looping the
drag, virtual mass, lift, etc..., models directly, the solver now calls
a set of phase-system methods which group the different force terms.
These new methods are documented in MomentumTransferPhaseSystem.H. Many
other accessors have been removed as a consequence of this grouping.
A bug was also fixed whereby the face-based algorithm was not
transferring the momentum associated with a given interfacial mass
transfer.
Without -fields specified mergeOrSplitBaffles now manipulates the mesh only and
with the -fields option also updates the fields corresponding to the mesh change.
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 ...
}
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.
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).
This removes a class of flux-velocity decoupling ("staggering") relating to the
interaction between the virtual mass, lift and turbulent dispersion forces.
First run the surfaceFeatureExtract with the "closeness" option enabled in the
surfaceFeatureExtractDict to extract the surface closeness point field
// Out put the closeness of surface elements to other surface elements.
closeness yes;
Then enable cell sizing based on local surface closeness by specifying the
"internalCloseness" options in the foamyHexMeshDict e.g.
motionControl
{
defaultCellSize 4;
minimumCellSizeCoeff 0.1;
maxSmoothingIterations 100;
maxRefinementIterations 2;
shapeControlFunctions
{
geometry
{
type searchableSurfaceControl;
priority 1;
mode inside;
surfaceCellSizeFunction nonUniformField;
cellSizeCalculationType automatic;
curvature false;
curvatureFile dummy;
featureProximity false;
featureProximityFile dummy;
internalCloseness true;
internalClosenessFile geometry.internalPointCloseness;
internalClosenessCellSizeCoeff 25;
curvatureCellSizeCoeff 0;
maximumCellSizeCoeff 1;
cellSizeFunction uniform;
}
}
}
The outletPhaseMeanVelocity and waveVelocity boundary conditions now
support a "ramp" keyword, for which a function can be supplied to
gradually increase the input velocity. The following is an example
specification for an outlet patch:
outlet
{
type outletPhaseMeanVelocity;
Umean 2;
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
alpha alpha.water;
}
There is also a new velocityRamping function object, which provides a
matching force within the volume of the domain, so that the entire flow
is smoothly accelerated up to the operating condition. An example
specification is as follows:
velocityRamping
{
type velocityRamping;
active on;
selectionMode all;
U U;
velocity (-2 0 0);
ramp
{
type quarterSineRamp;
start 0;
duration 5;
}
}
These additions have been designed to facilitate a smoother startup of
ship simulations by avoiding the slamming transients associated with
initialising a uniform velocity field.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
chtMultiRegionSimpleFoam needs to check whether or not the simulation is
at the end. To facilitate this, a Time::running method has been added.
The Time::run method was being used for this purpose, but this lead to
function objects being executed multiple times.
This resolves bug report https://bugs.openfoam.org/view.php?id=2804
Removed possibility for the user to specify a driftRate in the constantDrift
model which is independent of a fvOptions mass source. The driftRate must be
calculated from/be consistent with the mass source in order to yield a particle
number conserving result.
Made calculation of the over-all Sauter mean diameter of an entire population
balance conditional on more than one velocityGroup being present. This diameter
field is for post-processing purposes only and would be redundant in case of one
velocityGroup being used.
Solution control is extended to allow for solution of the population balance
equation at the last PIMPLE loop only, using an optional switch. This can be
beneficial in terms of simulation time as well as coupling between the
population balance based diameter calculation and the rest of the equation
system.
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
allow renormalization of sizeGroup volume fractions for restarts involving
initial conditions with a slight degree of unboundedness
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
which provides access to the current phase and the corresponding other phase for
each of the phases in the pair. This allows some simplification of the phase
pair loops in several sub-models and avoids the need for pointer swaps.
Checking a pair contains a particular phase and adding a contribution from the
"other" phase can now be written:
if (pair.contains(phase))
{
const phaseModel& otherPhase = pair.other(phase);
phiHbyAs[phasei] +=
fvc::interpolate(rAUs[phasei]*K)
*MRF.absolute(otherPhase.phi());
HbyAs[phasei] += rAUs[phasei]*K*otherPhase.U();
}
which previously would have been written as a loop over the pair and excluding
self reference:
const phaseModel* phase1 = &pair.phase1();
const phaseModel* phase2 = &pair.phase2();
forAllConstIter(phasePair, pair, iter)
{
if (phase1 == &phase)
{
phiHbyAs[phasei] +=
fvc::interpolate(rAUs[phasei]*K)
*MRF.absolute(phase2->phi());
HbyAs[phasei] += rAUs[phasei]*K*phase2->U();
}
Swap(phase1, phase2);
}
