The phase-fraction filtering of the compressibility terms is present to avoid
spurious phase-change due to numerical noise. The fvModels contribution may
cause physical phase-change due to cavitation, boiling, transfer from film or
VoF even where none of the phase is present and hence must be added after the
compressibility filtering.
With VoFClouds and VoFSurfaceFilm compressibleInterFoam supports Lagrangian
clouds which can impinge on walls forming a film which in turn can transfer to
the VoF when the film is thick enough to resolve. The new tutorial case
tutorials/multiphase/compressibleInterFoam/laminar/cylinder
is provided to demonstrate this functionality.
Direct transfer of droplets to the VoF phase is not yet supported but will be
added later.
Now the VoFSurfaceFilm library is optionally loaded at run-time for cases that
require surface film by adding the optional "libs" entry in controlDict:
libs ("libVoFSurfaceFilm.so");
See tutorials/multiphase/compressibleInterFoam/laminar/plateFilm
Now the VoFSurfaceFilm library is optionally loaded at run-time for cases that
require surface film by adding the optional "libs" entry in controlDict:
libs ("libVoFSurfaceFilm.so");
See tutorials/multiphase/compressibleInterFoam/laminar/plateFilm
in particular for equations of state which do not support coefficient mixing
required by equilibrium constant evaluation in reactions.
Also improved the set of pre-compiled combinations of properties and mixing
rules.
To provide more flexibility, extensibility, run-time modifiability and
consistency the handling of optional pressure limits has been moved from
pressureControl (settings in system/fvSolution) to the new limitPressure
fvConstraint (settings in system/fvConstraints).
All tutorials have been updated which provides guidance when upgrading cases but
also helpful error messages are generated for cases using the old settings
providing specific details as to how the case should be updated, e.g. for the
tutorials/compressible/rhoSimpleFoam/squareBend case which has the pressure
limit specification:
SIMPLE
{
...
pMinFactor 0.1;
pMaxFactor 2;
...
generates the error message
--> FOAM FATAL IO ERROR:
Pressure limits should now be specified in fvConstraints:
limitp
{
type limitPressure;
minFactor 0.1;
maxFactor 2;
}
file: /home/dm2/henry/OpenFOAM/OpenFOAM-dev/tutorials/compressible/rhoSimpleFoam/squareBend/system/fvSolution/SIMPLE from line 41 to line 54.
Now that dynamic compilation of thermo and chemistry is available it is no
longer necessary or useful to instantiate vast numbers of thermo combinations
within the standard OpenFOAM libraries. This reduces compile time, library size
and simplifies maintenance.
divU is cached before mesh-motion and mapped post-motion to drive the optional pcorr flux
update to ensure the fluxes are conservative following mesh motion and change.
The phase system now have the ability to specify the derivative of mass
transfer rates w.r.t. pressure. This permits implicit handling of
pressure-coupled mass transfer processes.
This implicit handling has been applied to the mass transfers that are
modelled by the thermal phase system. This should result in significant
stability improvements. The implicit handling can be toggled on or off
by means of a "pressureImplicit" switch in constant/phaseProperties. It
is on by default.
Patch contributed by Juho Peltola, VTT.
The former implementation of the daughterSizeDistributionModel based on
Laakkonen et al. (2006) had the issue of not conserving the total
particle number and volume properly, except when the coefficient C4 is
set to a value of 2. The issue is solved by following the work of
Laakkonen et al. (2007).
The default coefficients in both the breakupModel and the
daughterSizeDistributionModel were updated as well according to the
suggestions of the authors.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
The current implementation of the uniform daughterSizeDistribution model
is not general enough to support uniform breakup into multiple fragments
while conserving both the total particle number and volume, except for
binary breakup (which was the default setting).
The model has therefore been renamed to uniformBinary, i.e. resulting in
two fragments.
It is currently used for verification purposes only. If the need for a
more general form arises, then that will require additional development.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
and VTT Technical Research Centre of Finland Ltd.
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
The constant heat capacity hacked thermo in surfaceFilmModels and the
corresponding transfer terms in Lagrangian have been replaced by the standard
OpenFOAM rhoThermo which provides a general handling of thermo-physical
properties, in particular non-constant heat capacity. Further rationalisation
of liquid and solid properties has also been undertaken in support of this work
to provide a completely consistent interface to sensible and absolute enthalpy.
Now for surfaceFilmModels the thermo-physical model and properties are specified
in a constant/<region>/thermophysicalProperties dictionary consistent with all
other types of continuum simulation.
This significantly rationalises, simplifies and generalises the handling of
thermo-physical properties for film simulations and is a start at doing the same
for Lagrangian.
pMin and pMax settings are now available in multiphaseEulerFoam in the
PIMPLE section of the system/fvOptions file. This is consistent with
other compressible solvers. The pMin setting in system/phaseProperties
is no longer read, and it's presence will result in a warning.
SLGThermo has been moved to lagrangian, which still depends on it, pending
complete removal and replacement with a more rational interface to the carrier
phase thermodynamics.
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
A population balance suffix after the phase suffix makes determining the
phase for a given name more complex. The additional suffix is also
unnecessary as a phase can only ever belong to one population balance,
so the phase name alone uniquely idetifies the grouping.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
Field corrections are effectively explicit constraints applied to the field
after solution rather than to the equation and it significantly simplifies the
implementation to treat them as a special case of constraints. To implement
this the fvOption::correct(<field>) function has been renamed
fvOption::constrain(<field>) and uses constrainsField and constrainedFields.
This replaces compressibleInterFilmFoam in a more flexible, general and easily
maintainable form. A compressibleInterFilmFoam script is provided to redirect
uses to the replacement functionality:
The compressibleInterFilmFoam solver has solver has been replaced by the more general
compressibleInterFoam solver, which now supports surface films using the new
VoFSurfaceFilm fvOption.
To run with with surface film create a system/fvOptions dictionary
containing the VoFSurfaceFilm specification, e.g.
VoFSurfaceFilm
{
type VoFSurfaceFilm;
phase water;
}
The paper of Prince and Blanch (1996) contains an error in equation (2),
which computes the collision cross-sectional area and should be using
the bubble diameter rather than the radius. This error also extends to
equation (8) where the coefficient is wrong by a factor of 4. The
current code is correct, but the documentation was still referring to
the wrong coefficient.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
reactingFoam and multiphaseEulerFoam can now both be run with the
frozenFlow switch and multiple outer correctors. This makes their
behaviour consistent with the frozenFlow implementation in
chtMultiRegionFoam.
The previous changes to reactions mean that caching the surface area
density field is no longer necessary. The diameter models have had their
caching functionality removed, which has simplified both the
implementation and the user interface.
A modified Arrhenius reaction rate given by:
k = (A * T^beta * exp(-Ta/T))*a
Where a is the phase surface area per unit volume. The name of the phase is
specified by the user.
Example usage:
oxidationAtSurface
{
type irreversiblePhaseSurfaceArrhenius;
reaction "O2^0 + TiCl4 = TiO2_s + 2Cl2";
A 4.9e1; // The pre-exponential factor is in units
// equal to that in the usual volumetric
// reaction rate **divided by length**, as
// the Arrhenius expression is taken to give
// rate per unit area, not per unit volume
beta 0.0;
Ta 8993;
phase particles;
}
This reaction has been applied to the titaniaSynthesisSurface tutorial,
which avoids the need for explicit caching of the surface area density
field.
A number of fvOptions that apply to a user-derined field can now
automatically work what primitive type they apply to. These options can
apply to any field type, and in some cases even multiple fields of
differing type. Example usage of the options to which this change
applies are shown below:
codedSource1
{
type codedSource;
name codedSource1;
field h;
...
}
fixedValueConstraint1
{
type fixedValueConstraint;
fieldValues
{
R (1 0 0 1 0 1);
epsilon 150;
}
...
}
phaseLimitStabilization11
{
type phaseLimitStabilization;
field sigma.liquid;
...
}
Previously to apply to a given type, these options had to be selected
with the name of the type prepended to the option name (e.g., "type
symmTensorPhaseLimitStabilization;") and those that operated on multiple
fields were restricted to those fields being of the same type.
A number of other options have had improvements made to their handling
of user specification of fields. Where possible, the option will now
attempt to work out what field the option applies to automatically. The
following options, therefore, no longer require "field" or "fields"
entries:
actuationDiskSource
buoyancyEnergy
buoyancyForce
meanVelocityForce
rotorDiskSource
volumeFractionSource
constantHeatTransfer
function2HeatTransfer
variableHeatTransfer
Non-standard field names can be overridden in the same way as in
boundary conditions; e.g., the velocity name can be overridden with a "U
<UName>;" entry if it does not have the default name, "U". The name of
the energy field is now always determined from the thermodynamics
model and should always be correct. Some options that can be applied to
an individual phase also support a "phase <phaseName>;" entry;
fvOptions field-name handling has been rewritten to increase its
flexibility and to improve warning messages. The flexibility now allows
for options that apply to all fields, or all fields of a given phase,
rather than being limited to a specific list of field names. Messages
warning about options that have not been applied now always print just
once per time-step.
