genericPatches is linked into mesh generation and manipulation utilities but not
solvers so that the solvers now check for the availability of the specified
patch types. Bugs in the tutorials exposed by this check have been corrected.
If the optional kinematic Bingham plastic yield stress sigmay [m^2/s^2] is
provided the viscosity is updated to include the Bingham plastic correction.
Class
Foam::solvers::film
Description
Solver module for flow of compressible liquid films
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,
radiation, surface film etc. and constraining or limiting the solution.
solvers::film is derived from solvers::isothermalFilm adding an energy equation
and temperature update with support for heat transfer to the wall using the
standard ThermophysicalTransportModels library utilising the filmWall patch type
or mappedFilmWall for CHT heat transfer to the adjacent solid region. A huge
advantage of this consistency with the rest of OpenFOAM is that the standard
thermal coupled boundary conditions can be used without modification, e.g.
temperatureCoupled.
Two variants of the rivuletPanel tutorial case are provided,
tutorials/modules/film/rivuletPanel demonstrates heat transfer to a fixed
temperature wall and tutorials/modules/CHT/rivuletPanel demonstrates conjugate
heat transfer to a thin aluminium panel simulated in a region using the
solvers::solid solver executed with solvers::film using foamMultiRun.
More functionality will be added through the power of fvModels.
Class
Foam::solvers::isothermalFilm
Description
Solver module for flow of compressible isothermal liquid films
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.
The implementation of this new film solver is in fully conservative form,
solving for the film volume-fraction rather film thickness which ensures
conservation on curved and irregular surfaces and even around corners.
Also the formulation is consistent with standard FV solvers in other fundamental
respects using boundary conditions rather than volume forces to apply surface
stresses and transfers. This hugely advantageous approach, which allows the
reuse of many of the standard OpenFOAM libraries, in particular standard
compressibleMomentumTransportModels for the wall and internal film stresses, is
achieved using the special patch types filmWall and filmSurface to handle the
difference between the film thickness and the film cell layer height.
The specification of physical properties, boundary conditions, optional models
etc. etc. is handled in the same manner as all the other solver modules, making
much easier to use and to maintain the code.
Currently only coupling to the wall is supported with laminar transport, surface
tension, a new and more accurate contact angle algorithm and gravity which is
sufficient to demonstrate rivulet flow for example as in the tutorial case
provided: tutorials/modules/isothermalFilm/rivuletPanel
Support for coupling to an adjacent fluid region, Lagrangian impingement and
ejection, transfer to and from a VoF phase etc. will be added in the future via
the standard fvModels interface.
e.g. in extrudeToRegionMeshDict:
// Generate the region named film
region film;
// from the patch extrudeWall
patches (extrudeWall);
// generating mapped patches for the extruded region
adaptMesh yes;
// New options:
// Set the type of the mapped patch on the existing mesh to mappedWall ...
patchTypes (mappedWall);
// ... and name to wall
patchNames (wall);
// Set the type of the mapped patch on the region mesh to mappedFilmWall ...
regionPatchTypes (mappedFilmWall);
// ... and name to wall
regionPatchNames (wall);
// Set the type of the opposite patch on the region mesh to empty ...
regionOppositePatchTypes (empty);
// ... and name to empty
regionOppositePatchNames (empty);
All the above entries are optional and if not present the previous behaviour is
reproduced.
This fvModel applies a mass source to the continuity equation and to all
field equations, in a zero-dimensional case. Correction is made to
account for the mass that exits the domain due to expansion in space, so
that the model correctly applies a total mass flow rate. It is
implemented as a light wrapper around the massSource model.
This permits further non-conformal connnection types to store additional
or alternative information in the fvMesh::polyFacesBf patch fields.
Previously, this field just used calculated patch fields types.
This change has required an update to the fvsPatchFields to make their
handling of IO of the value field consistent with the fvPatchFields. The
base class no longer writes out the value field by default.
used in the alphaContactAngleFvPatchScalarField boundary condition to replace
the need to derive specialised versions for different contact angle evaluation
methods. This simplifies the code and provides a reusable system which could be
applied to other multiphase contact angle boundary conditions.
These are not used anywhere. interpolateSplineXY's functionality can be
achieved with a table function1, and patchToPatchInterpolation has been
superseded at least twice; first by AMI and then by patchToPatch/NCC.
Solver modules have replaced code that was previously shared between
solvers by means of #include-ing header files. Some of these headers are
now unused and have been removed. Others are only now used in a single
solver and have been moved into that solver.
This change applies to diameter models within the multiphaseEuler
module, heat transfer fvModels, and the LopesdaCosta porosity and
turbulence models.
User input changes have been made backwards-compatible, so existing
AoV/a/Sigma/... entries and fields should continue to work.
Latent heat evaluation has been changed to calculate both sides' heats
similarly using the interface temperature, rather than using bulk
quantities on the "upwind" side of the mass transfer process
(latentHeatScheme::symmetric vs latentHeatScheme::upwind).
The transfer of heat has been changed so that it is calculated from the
mass transfer rate rather than the heat transfer coefficients and
temperatures (latentHeatTransfer::mass vs latentHeatTransfer::heat).
These changes were found to improve stability characteristics in some
boiling cases, and in general should be more energy conservative and
less dependent on the accuracy of the interfacial temeprature solution.
Patch contributed by Juho Peltola, VTT.
The new option takes a value indicating which cell types should be
written out as polyhedra. The values are as follows:
none: No polyhedral cells are written. Cells which match specific
shapes (hex, pyramid, prism, ...) are written as their
corresponding VTK cell types. Arbitrary polyhedral cells
that do not match a specific shape are decomposed into
tetrahedra.
polyhedra: Only arbitrary polyhedral cells are written as a VTK
polyhedron. Cells that match specific shapes are written as
their corresponding VTK cell types.
all: All cells are written as a VTK polyhedron.
The default is 'none', which retains the previous default behaviour.
Two pitzDaily variants have been added; pitzDailySteadyMappedToPart, and
pitzDailySteadyMappedToRefined. These demonstrate usage of workflows
which involve mapping between cases with mapFieldsPar.
The pitzDailySteadyMappedToPart case demonstrates mapping onto a small
section of the mesh; in this case in the vicinity of the the corner of
the backstep. This mesh is not consistent with the source data, so
fields are required in the zero directory and cutting patches are used
to specify the properties at the inlets.
The pitzDailySteadyMappedToRefined case demonstrates mapping onto a
geometrically similar case with a different mesh density. This mesh is
consistent with the source, so no fields are needed and no cutting
patches are used. This case does, however, perturb the geometry of the
block mesh a bit, so that some of the refined case is not overlapping
the original case. This provides a test of the stabilisation
procedures within the mesh-to-mesh mapping functions.
Stabilisation has been added to the mapping of fields between consistent
meshes. This means that if part of the target mesh is found not to
connect with the source mesh, then its values will be set by propagating
a value from the closest part of the target mesh did successfully
connect to the source. This propagation is achieved by means of a mesh
wave.
This stabilisation applies to both cell and patch fields, and any and
all ancillary fields that may be being stored by the patch boundary
conditions. It applies to the mapping performed by both mapFieldsPar and
the run-time mapping meshToMesh topology changer.
This fixes the previous situation in mapping between consistent meshes
in which target elements which did not connect to the source would be
given an undefined value, which would cause either a floating point
error, or (worse) incorrect operation.
Cell-to-cell interpolation has been moved to a hierarchy separate from
meshToMesh, called cellsToCells. The meshToMesh class is now a
combination of a cellsToCells object and multiple patchToPatch objects.
This means that when only cell-to-cell interpolation is needed a basic
cellsToCells object can be selected.
Cell-to-cell and vol-field-to-vol-field interpolation now has two well
defined sets of functions, with a clear distinction in how weights that
do not sum to unity are handled. Non-unity weights are either
normalised, or a left-over field is provided with which to complete the
weighted sum.
The left-over approach is now consistently applied in mapFieldsPar,
across both the internal and patch fields, if mapping onto an existing
field in the target case. Warning are now generated for invalid
combinations of settings, such as mapping between inconsistent meshes
without a pre-existing target field.
All mapping functions now take fields as const references and return tmp
fields. This avoids the pattern in which non-const fields are provided
which relate to the source, and at some point in the function transfer
to the target. This pattern is difficult to reason about and does not
provide any actual computational advantage, as the fields invariably get
re-allocated as part of the process anyway.
MeshToMesh no longer stores the cutting patches. The set of cutting
patches is not needed anywhere except at the point of mapping a field,
so it is now supplied to the mapping functions as an argument.
The meshToMesh topology changer no longer supports cutting patch
information. This did not previously work. Cutting patches either get
generated as calculated, or they require a pre-existing field to specify
their boundary condition. Neither of these options is suitable for a
run-time mesh change.
More code has been shared with patchToPatch, reducing duplication.
