An additional layer has been added into the phase system hierarchy which
facilitates the application of phase transfer modelling. These are
models which exchange mass between phases without the thermal coupling
that would be required to represent phase change. They can be thought of
as representation changes; e.g., between two phases representing
different droplet sizes of the same physical fluid.
To facilitate this, the heat transfer phase systems have been modified
and renamed and now both support mass transfer. The two sided version
is only required for derivations which support phase change.
The following changes to case settings have been made:
- The simplest instantiated phase systems have been renamed to
basicTwoPhaseSystem and basicMultiphaseSystem. The
heatAndMomentumTransfer*System entries in constant/phaseProperties files
will need updating accordingly.
- A phaseTransfer sub-model entry will be required in the
constant/phaseProperties file. This can be an empty list.
- The massTransfer switch in thermal phase change cases has been renamed
phaseTransfer, so as not to be confused with the mass transfer models
used by interface composition cases.
This work was supported by Georg Skillas and Zhen Li, at Evonik
The implementation of the porousBafflePressure BC was incorrect in OpenFOAM-2.4
and earlier and corrected during the turbulence modeling rewrite for
OpenFOAM-3.0. This update introduced the density scaling required for the
definition of pressure in interFoam which requires the porosity coefficients to
be reduced.
Resolves bug-report https://bugs.openfoam.org/view.php?id=2890
Also added tutorial case demonstrating usage. Note that the new drag
models are symmetric and should be used without any blending.
This work was supported by Georg Skillas and Zhen Li, at Evonik
Sub-model blending should be set such that the sum of all the blending
coefficients equals one. If there are three models specified for a phase
pair (e.g., (air in water), (water in air) and (air and water)), then
the sum-to-one constraint is guaranteed by the blending functions.
Frequently, however, the symmetric model ((air and water) in this
example) is omitted. In that case, the blending coefficients should be
selected so that the sum of just the two non-symmetric coefficients
equal one.
In the case of linear blending, this means setting the minimum partially
continuous alpha to one-minus the fully continuous value of the opposite
phase. For example:
blending
{
default
{
type linear;
minFullyContinuousAlpha.air 0.7;
minPartlyContinuousAlpha.air 0.3;
minFullyContinuousAlpha.water 0.7;
minPartlyContinuousAlpha.water 0.3;
}
}
The reactingTwoPhaseEulerFoam and reactingMultiPhaseEulerFoam tutorials
have been modified to adhere to this principle.
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
The initial set of cases in the test directory are aimed at testing the
reactingEulerFoam populationBalance functionality.
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum
Dresden - Rossendorf (HZDR) and VTT Technical Research Centre of Finland Ltd.
Integrated with the "tutorials" functionality by CFD Direct Ltd.
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
Replaced the ad hoc geometric mean blending with the more physical wall distance
Reynolds number blending function.
Additionally the part of the production term active for y+ < 11.6 has been
reinstated.
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.
This change means that getApplication still works if we have a
controlDict.orig, rather than a controlDict. This allows us to simplify
the scripting of tutorials in which the controlDict is modified.
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.
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
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 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).
The onset of vertical damping can now be graduated over a distance. The
user specifies an origin and a direction along which the graduation
occurs, and a ramping function to specify the form of the graduation. An
example specification for the fvOption is:
verticalDamping1
{
type verticalDamping;
selectionMode all;
origin (1200 0 0);
direction (1 0 0);
ramp
{
type halfCosineRamp;
start 0;
duration 600;
}
lambda [0 0 -1 0 0 0 0] 1; // Damping coefficient
timeStart 0;
duration 1e6;
}
If the origin, direction or ramp entries are omitted then the fvOption
functions as before; applying the damping to the entire volume or the
specified cell set.
This work was supported by Jan Kaufmann and Jan Oberhagemann at DNV GL.
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.
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.
This patch enables the reactingEulerFoam solvers to simulate polydisperse flow
situations, i.e. flows where the disperse phase is subject to a size
distribution.
The newly added populationBalanceModel class solves the integro-partial
differential population balance equation (PBE) by means of a class method, also
called discrete or sectional method. This approach is based on discretizing the
PBE over its internal coordinate, the particle volume. This yields a set of
transport equations for the number concentration of particles in classes with a
different representative size. These are coupled through their source-terms and
solved in a segregated manner. The implementation is done in a way, that the
total particle number and mass is preserved for coalescence, breakup and drift
(i.e. isothermal growth or phase change) processes, irrespective of the chosen
discretization over the internal coordinate.
A population balance can be split over multiple velocity (temperature) fields,
using the capability of reactingMultiphaseEulerFoam to solve for n momentum
(energy) equations. To a certain degree, this takes into account the dependency
of heat- and momentum transfer on the disperse phase diameter. It is also possible
to define multiple population balances, e.g. bubbles and droplets simultaneously.
The functionality can be switched on by choosing the appropriate phaseSystem
type, e.g. populationBalanceMultiphaseSystem and the newly added diameterModel
class called velocityGroup. To illustrate the use of the functionality, a
bubbleColumnPolydisperse tutorial was added for reactingTwoPhaseEulerFoam and
reactingMultiphaseEulerFoam.
Furthermore, a reactingEulerFoam-specific functionObject called sizeDistribution
was added to allow post-Processing of the size distribution, e.g. to obtain the
number density function in a specific region.
Patch contributed by Institute of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf
(HZDR) and VTT Technical Research Centre of Finland Ltd.
- Thermal phase change and wall boiling functionality has been generalized to
support two- and multi- phase simulations.
- Thermal phase change now also allows purePhaseModel, which simplifies case setup.
- The phaseSystem templates have been restructured in preparation of multiple
simultaneous mass transfer mechanisms. For example, combination of thermal phase
and inhomogeneous population balance models.
Patch contributed by VTT Technical Research Centre of Finland Ltd and Institute
of Fluid Dynamics, Helmholtz-Zentrum Dresden - Rossendorf (HZDR).
A pureMixture can now be specified in a reacting solver. This further
enhances compatibility between non-reacting and reacting solvers.
To achieve this, mixtures now have a typeName function of the same form
as the lower thermodyanmic models. In addition, to avoid name clashes,
the reacting thermo make macros have been split into those that create
entries on multiple selection tables, and those that just add to the
reaction thermo table.
