setFormat no longer defaults to the value of graphFormat optionally set in
controlDict and must be set in the functionObject dictionary.
boundaryFoam, financialFoam and pdfPlot still require a graphFormat entry in
controlDict but this is now read directly rather than by Time.
The parcelsPerSecond control can now be specified as a time-varying
function. This provides additional control over the temporal
distribution of injected parcels, which may be advantageous if, for
example, the mass flow rate varies significantly. It also enables
variable flow rates of particulates in cases which have a fixed number
of particles per parcel.
Description
fvMeshTopoChanger which maps the fields to a new mesh or sequence of meshes
which can optionally be mapped to repeatedly for example in multi-cycle
engine cases or cycled through for symmetric forward and reverse motion.
Usage
\table
Property | Description | Required | Default value
libs | Libraries to load | no |
times | List of times for the meshes | yes |
repeat | Repetition period | no |
cycle | Cycle period | no |
begin | Begin time for the meshes | no | Time::beginTime()
timeDelta | Time tolerance used for time -> index | yes |
\endtable
Examples of the mesh-to-mesh mapping for the multi-cycle
tutorials/incompressibleFluid/movingCone case:
\verbatim
topoChanger
{
type meshToMesh;
libs ("libmeshToMeshTopoChanger.so");
times (0.0015 0.003);
cycle #calc "1.0/300.0";
begin 0;
timeDelta 1e-6;
}
\endverbatim
If the libs entry is not provided and the name of the library containing the
functionObject, fvModel or fvConstraint corresponds to the type specified the
corresponding library is automatically loaded, e.g. to apply the
VoFTurbulenceDamping fvModel to an incompressibleVoF simulation the following
will load the libVoFTurbulenceDamping.so library automatically and instantiate
the fvModel:
turbulenceDamping
{
type VoFTurbulenceDamping;
delta 1e-4;
}
This avoids potential hidden run-time errors caused by solvers running with
boundary conditions which are not fully specified. Note that "null-constructor"
here means the constructor from patch and internal field only, no data is
provided.
Constraint and simple BCs such as 'calculated', 'zeroGradient' and others which
do not require user input to fully specify their operation remain on the
null-constructor table for the construction of fields with for example all
'calculated' or all 'zeroGradient' BCs.
A special version of the 'inletOutlet' fvPatchField named 'zeroInletOutlet' has
been added in which the inlet value is hard-coded to zero which allows this BC
to be included on the null-constructor table. This is useful for the 'age'
functionObject to avoid the need to provide the 'age' volScalarField at time 0
unless special inlet or outlet BCs are required. Also for isothermalFilm in
which the 'alpha' field is created automatically from the 'delta' field if it is
not present and can inherit 'zeroInletOutlet' from 'delta' if appropriate. If a
specific 'inletValue' is require or other more complex BCs then the 'alpha'
field file must be provided to specify these BCs as before.
Following this improvement it will now be possible to remove the
null-constructors from all fvPatchFields not added to the null-constructor
table, which is most of them, thus reducing the amount of code and maintenance
overhead and making easier and more obvious to write new fvPatchField types.
which allows lambda to set higher in the cells adjacent to the boundary which is
particularly useful when solving for waves in a domain with no mean-flow and
wave BCs to avoid numerical stability problems where the specified wave flow
reverses into the domain. The alternative is to use symmetry rather than wave
BCs on the side patches which is stable without using lambdaBoundary but there
is modest distortion of the wave profile adjacent to the side patches which does
not propagate into the domain due to the wave forcing.
to demonstrate motion of a floating object due to waves without any mean flow,
generated by the waveForcing fvModel using the waves specification in
constant/waveProperties which is also used for the side boundary conditions.
The new general multi-region framework using the isothermalFilm and film solver
modules and executed with foamMultiRun is a much more flexible approach to the
inclusion of liquid films in simulations with the support for coupling to other
regions of various types e.g. gas flows, Lagrangian clouds, VoF, CHT etc. This
has all been achieved with a significant reduction in the number of lines of
code and significant improvements in code structure, readability and
maintainability.
The filmCloudTransfer fvModel now supports an optional ejection model which
provides transfer of film to cloud by dripping from an inverted surface or
curvature separation:
Class
Foam::filmEjectionModels::dripping
Description
Dripping film to cloud ejection transfer model
On an inverted surface if the film thickness is sufficient to generate a
valid parcel the equivalent mass is removed from the film and transfered to
the cloud as a parcel containing droplets with a diameter obtained from
the specified parcelDistribution.
Usage
Example usage:
\verbatim
filmCloudTransfer
{
type filmCloudTransfer;
libs ("libfilmCloudTransfer.so");
ejection
{
model dripping;
deltaStable 5e-4;
minParticlesPerParcel 10;
parcelDistribution
{
type RosinRammler;
Q 0;
min 1e-3;
max 2e-3;
d 7.5e-05;
n 0.5;
}
}
}
\endverbatim
Class
Foam::filmEjectionModels::BrunDripping
Description
Brun dripping film to cloud ejection transfer model
If the film thickness exceeds the critical value needed to generate one or
more drops, the equivalent mass is removed from the film. The critical film
thickness is calculated from the Rayleigh-Taylor stability analysis of film
flow on an inclined plane by Brun et.al.
Reference:
\verbatim
Brun, P. T., Damiano, A., Rieu, P., Balestra, G., & Gallaire, F. (2015).
Rayleigh-Taylor instability under an inclined plane.
Physics of Fluids (1994-present), 27(8), 084107.
\endverbatim
The diameter of the drops formed are obtained from the local capillary
length multiplied by the \c dCoeff coefficient which defaults to 3.3.
Reference:
\verbatim
Lefebvre, A. (1988).
Atomisation and sprays
(Vol. 1040, No. 2756). CRC press.
\endverbatim
Usage
Example usage:
\verbatim
filmCloudTransfer
{
type filmCloudTransfer;
libs ("libfilmCloudTransfer.so");
ejection
{
model BrunDripping;
deltaStable 5e-4;
}
}
\endverbatim
Class
Foam::filmEjectionModels::curvatureSeparation
Description
Curvature induced separation film to cloud ejection transfer model
Assesses film curvature via the mesh geometry and calculates a force
balance of the form:
F_sum = F_inertial + F_body + F_surface_tension
If F_sum < 0, the film separates and is transferred to the cloud
if F_sum >= 0 the film remains attached.
Reference:
\verbatim
Owen, I., & Ryley, D. J. (1985).
The flow of thin liquid films around corners.
International journal of multiphase flow, 11(1), 51-62.
\endverbatim
Usage
Example usage:
\verbatim
filmCloudTransfer
{
type filmCloudTransfer;
libs ("libfilmCloudTransfer.so");
ejection
{
model curvatureSeparation;
deltaStable 5e-4;
}
}
\endverbatim
The new tutorials/modules/multiRegion/film/cylinderDripping tutorial case
demonstrates a film dripping into the cloud. The standard cylinder case is
turned upside-down (by changing the orientation of gravity) with an initial
0.2mm film of water over the surface which drips when the thickness is greater
than 0.5mm. Settings for all three ejection models are provided in the
constant/film/fvModels dictionary with the standard dripping model selected.
Lagrangian injections now have a 'uniformParcelSize' control, which
specifies what size of the parcels is kept uniform during a given time
step. This control can be set to 'nParticles', 'surfaceArea' or
'volume'. The particle sizes, by contrast, are specified by the size
distribution.
For example, if 'uniformParcelSize nParticles;' is specified then all
parcels introduced at a given time will have the same number of
particles. Every particle in a parcel has the same properties, including
diameter. So, in this configuration, the larger diameter parcels contain
a much larger fraction of the total particulate volume than the smaller
diameter ones. This may be undesirable as the effect of a parcel on the
simulation might be more in proportion with its volume than with the
number of particles it represents. It might be preferable to create a
greater proportion of large diameter parcels so that their more
significant effect is represented by a finer Lagrangian discretisation.
This can be achieved by setting 'uniformParcelSize volume;'. A setting
of 'uniformParcelSize surfaceArea;' might be appropriate if the limiting
effect of a Lagrangian element scales with its surface area; interfacial
evaporation, for example.
Previously, this control was provided by 'parcelBasisType'. However,
this control also effectively specified the size exponent of the
supplied distribution. This interdependence was not documented and was
problematic in that it coupled physical and numerical controls.
'parcelBasisType' has been removed, and the size exponent of the
distribution is now specified independently of the new
'uniformParcelSize' control along with the rest of the distribution
coefficients or data. See the previous commit for details.
It is still possible to specify a fixed number of particles per parcel
using the 'nParticle' control. The presence of this control is used to
determine whether or not the number of particles per parcel is fixed, so
a 'fixed' basis type is no longer needed.
A number of bugs have been fixed with regards to lack of
interoperability between the various settings in the injection models.
'uniformParcelSize' can be changed freely and the number of parcels and
amount of mass that an injector introduces will not change (this was not
true of 'parcelBasisType'). Redundant settings are no longer read by the
injection models; e.g., mass is not read if the number of particles per
parcel is fixed, duration is not specified for steady tracking, etc...
The 'inflationInjection' model has been removed as there are no examples
of its usage, its purpose was not clearly documented, and it was not
obvious how it should be updated as a result of these changes.
This completes commit 381e0921 and permits patches on the "top" of
extruded regions to determine the point locations opposite as well as
the face centres and areas. This means that patches with dissimilar
meshes can now be coupled via the patchToPatch interpolation engine.
A few fixes have also been applied to extrudeToRegionMesh to make the
intrude option compatibile with extrusion into internal faces and
between opposing zones/sets/patches. The 'shadow' entries used for
extrusion inbetween opposing zones/sets/patches have also been renamed
to 'opposite' for consistency with the patch names and patch types
entries; e.g.,
faceZones (fz1 fz3);
oppositeFaceZones (fz2 fz4); // <-- was 'faceZonesShadow'
faceSets (fs1 fs3);
oppositeFaceSets (fs2 fs4); // <-- was 'faceSetsShadow'
patches (p1 p3);
oppositePatches (p2 p4); // <-- was 'patchesShadow'
With the new film implementation the single cell layer film region is extruded
into (overlapping with) the primary/fluid region which can now be generated with
extrudeToRegionMesh using the new 'intrude' option, e.g. for the
tutorials/modules/multiRegion/film/splashPanel case the extrudeToRegionMeshDict
contains:
region film;
patches (film);
extrudeModel linearNormal;
intrude yes;
adaptMesh no;
patchTypes (mappedExtrudedWall);
patchNames (film);
regionPatchTypes (filmWall);
regionPatchNames (wall);
regionOppositePatchTypes (mappedFilmSurface);
regionOppositePatchNames (surface);
nLayers 1;
expansionRatio 1;
linearNormalCoeffs
{
thickness 0.002;
}
The parcel transfer occurs from the cloudFilmTransfer surfaceFilmModel specified
in the <fluid> region constant/<fluid>/cloudProperties dictionary:
.
.
.
libs ("libfilmCloudTransfer.so");
.
.
.
surfaceFilmModel cloudFilmTransfer;
and the film filmCloudTransfer specified in the <film> region
constant/<film>/fvModels dictionary:
.
.
.
filmCloudTransfer
{
type filmCloudTransfer;
libs ("libfilmCloudTransfer.so");
}
For an example of cloud->film->VoF transfer see the
tutorials/modules/multiRegion/film/cylinder tutorial case.
Note that parcel transfer from film to Lagrangian cloud is not yet supported,
this will be added soon.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces driftFluxFoam and all the corresponding
tutorials have been updated and moved to
tutorials/modules/incompressibleDriftFlux.
Class
Foam::solvers::incompressibleDriftFlux
Description
Solver module for 2 incompressible fluids using the mixture approach with
the drift-flux approximation for relative motion of the phases, with
optional mesh motion and mesh topology changes including adaptive
re-meshing.
The momentum and other fluid properties are of the "mixture" and a single
momentum equation is solved with mixture transport modelling in which a
single laminar, RAS or LES model is selected to model the momentum stress.
Uses the flexible PIMPLE (PISO-SIMPLE) solution for time-resolved and
pseudo-transient and steady simulations.
Optional fvModels and fvConstraints are provided to enhance the simulation
in many ways including adding various sources, Lagrangian
particles, surface film etc. and constraining or limiting the solution.
SourceFiles
incompressibleDriftFlux.C
See also
Foam::solvers::VoFSolver
Foam::solvers::twoPhaseVoFSolver
Foam::solvers::compressibleVoF
A constraint and a model have been added, both called
zeroDimensionalFixedPressure, that together act to maintain a pressure
constraint in a zero-dimensional case. These must be used
simultaneously. The desired pressure can be specified as a time-varying
Function1.
These replace the pressureConstraintSource, which has been removed.
The new classes operate by obtaining the residual of the complete
pressure equation, and using that to calculate the mass or volume
sources that need adding to the fluid in order to maintain the
constraint. This process is far more convergent than the previous
approach, it does not require the fluid to have a certain thermodynamic
model, and it is generalisable to multiphase.
This functionality requires only minimal specification. The constraint
contains all the settings and should be specified in
system/fvConstraints as follows:
zeroDimensionalFixedPressure1
{
type zeroDimensionalFixedPressure;
// Name of the pressure field, default = p
//p p;
// Name of the density field, default = rho
//rho rho;
// Constant pressure value
pressure 1e5;
//// Time-varying pressure value
//pressure
//{
// type table;
// values
// (
// (0 1e5)
// (1 1e5)
// (1.1 1.4e5)
// (10 1.4e5)
// );
//}
}
The model is then added to constant/fvModels, and requires no settings:
zeroDimensionalFixedPressure1
{
type zeroDimensionalFixedPressure;
}
compressibleVoF supports cavitation fvModels which provide a more physical and
controllable approach to cavitation modelling than the simple homogeneous
equilibrium approximation used in cavitatingFoam.
The tutorials/multiphase/cavitatingFoam/RAS/throttle case has been converted to
tutorials/modules/compressibleVoF/throttle which demonstrates how to update
cases from cavitatingFoam to compressibleVoF.
A cavitatingFoam script is provided to redirect users to update their cases to
compressibleVoF.
