A new nonConformalMappedWall patch type has been added which can couple
between different regions of a multi-region simulation. This patch type
uses the same intersection algorithm as the nonConformalCyclic patch,
which is used for coupling sections of a mesh within the same region.
The nonConformalMappedWall provides some advantages over the existing
mappedWall patches:
- The connection it creates is not interpolative. It creates a pair of
coupled finite-volume faces wherever two opposing faces overlap.
There is therefore no interpolation error associated with mapping
values across the coupling.
- Faces (or parts of faces) which do not overlap are not normalised
away by an interpolation or averaging process. Instead, they are
assigned an alternative boundary condition; e.g., an external
constraint, or even another non-conformal cyclic or mapped wall.
This makes the system able to construct partially-overlapping
couplings.
- The direct non-interpolative transfer of values between the patches
makes the method equivalent to a conformal coupling. Properties of
the solution algorithm, such as conservation and boundedness, are
retained regardless of the non-conformance of the boundary meshes.
- All constructed finite volume faces have accurate centre points.
This makes the method second order accurate in space.
Usage:
Non-conformal mapped wall couplings are constructed as the last stage of
a multi-region meshing process. First, a multi-region mesh is
constructed in one of the usual ways, but with the boundaries specified
as standard non-coupled walls instead of a special mapped type. Then,
createNonConformalCouples is called to construct non-conformal mapped
patches that couple overlapping parts of these non-coupled walls. This
process is very similar to the construction of non-conformal cyclics.
createNonConformalCouples requires a
system/createNonConformalCouplesDict in order to construct non-conformal
mapped walls. Each coupling is specified in its own sub-dictionary, and
a "regions" entry is used to specify the pair of regions that the
non-conformal mapped wall will couple. Non-conformal cyclics can also be
created using the same dictionary, and will be assumed if the two
specified regions are the same, or if a single "region" entry is
specified. For example:
// Do not modify the fields
fields no;
// List of non-conformal couplings
nonConformalCouples
{
// Non-conformal cyclic interface. Only one region is specified.
fluidFluid
{
region fluid;
originalPatches (nonCoupleRotating nonCoupleStationary);
}
// Non-conformal mapped wall interface. Two different regions
// have been specified.
fluidSolid
{
regions (fluid solid);
originalPatches (nonCoupleRotating nonCoupleStationary);
}
}
After this step, a case should execute with foamMultiRun and decompose
and reconstruct and post-process normally.
One additional restriction for parallelised workflows is that
decomposition and reconstruction must be done with the -allRegions
option, so that the both sides of the coupling are available to the
decomposition/reconstruction algorithm.
Tutorials:
Two tutorials have been added to demonstrate use of this new
functionality:
- The multiRegion/CHT/misalignedDuct case provides a simple visual
confirmation that the patches are working (the exposed corners of
the solid will be hot if the non-conformal mapped walls are active),
and it demonstrates createNonConformalCouples's ability to add
boundary conditions to existing fields.
- The multiRegion/CHT/notchedRoller case demonstrates use of
non-conformal mapped walls with a moving mesh, and also provides an
example of parallelised usage.
Notes for Developers:
A coupled boundary condition now uses a new class,
mappedFvPatchBaseBase, in order to perform a transfer of values to or
from the neighbouring patch. For example:
// Cast the patch type to it's underlying mapping engine
const mappedFvPatchBaseBase& mapper =
mappedFvPatchBaseBase::getMap(patch());
// Lookup a field on the neighbouring patch
const fvPatchScalarField& nbrTn =
mapper.nbrFvPatch().lookupPatchField<volScalarField, scalar>("T");
// Map the values to this patch
const scalarField Tn(mapper.fromNeighbour(nbrTn));
For this to work, the fvPatch should be of an appropriate mapped type
which derives from mappedFvPatchBaseBase. This mappedFvPatchBaseBase
class provides an interface to to both conformal/interpolative and
non-conformal mapping procedures. This means that a coupled boundary
condition implemented in the manner above will work with either
conformal/interpolative or non-conformal mapped patch types.
Previously, coupled boundary conditions would access a mappedPatchBase
base class of the associated polyPatch, and use that to transfer values
between the patches. This direct dependence on the polyPatch's mapping
engine meant that only conformal/interpolative fvPatch fields that
corresponded to the polyPatch's geometry could be mapped.
This provides finer control as to when the changes get constructed and
initial stitching is performed. These is needed by certain processes,
notably decomposition and reconstruction.
By default, the mesh still performs all these operations on a "normal"
read-construction. A flag has to be passed explicitly to the constructor
in order to prevent the post-construction steps.
This prevents spurious factors of 1000 from being introduced in
thermodynamic models. It also generalises the system further with
respect to alternative unit sets.
The specie molecular mass (Wi) and formation enthalpy (hfi) methods now
return dimensioned scalars. This permits their direct inclusion into
dimensioned field expressions. Non-dimensioned methods have been
retained with a "Value" suffix (i.e., WiValue and hfiValue).
These classes permit any PtrList of region-associated objects (meshes,
solvers, domainDecompositions, ...) to prefix the region name to the log.
At present these classes are used by decomposePar and reconstructPar
only. The foamMultiRun solver still handles its own prefixing.
Mixture classes (e.g., pureMixtrure, coefficientMulticomponentMixture),
now have no fvMesh or volScalarField dependence. They operate on
primitive values only. All the fvMesh-dependent functionality has been
moved into the base thermodynamic classes. The 'composition()' access
function has been removed from multi-component thermo models. Functions
that were once provided by composition base classes such as
basicSpecieMixture and basicCombustionMixture are now implemented
directly in the relevant multi-component thermo base class.
at Function1s of time.
Underlying this new functionObject is a generalisation of the handling of the
maximum time-step in the modular solvers to allow complex user-specification of
the maximum time-step used in a simulation, not just the time-dependency
provided by fluidMaxDeltaT but functions of anything in the simulation by
creating a specialised functionObject in which the maxDeltaT function is
defined.
The chemical and combustion time-scale functionObjects adjustTimeStepToChemistry
and adjustTimeStepToCombustion have been updated and simplified using the above
mechanism.
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.
gcc-13 has new code checking and warning mechanisms which are useful but not
entirely robust and produce many false positives, particularly with respect to
local references:
warning: possibly dangling reference to a temporary
This commit resolves many of the new warning messages but the above false
warnings remain. It is possible to switch off this warning but as it also
provides some useful checks it is currently left on.
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.
This ensures that all fvModels in all regions are updated before continuity is
predicted in any region so that inter-region mass transfers are included in the
region continuity equations.
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.
The calculation of the diffusion number has been put into a form
consistent with finite-volume, rather than the finite-difference form
that was used previously.
This difference in formulations is analogus to that of the Courant
number in the fluid solvers. Whilst a textbook will typically define the
courant number as equal to 'U*deltaT/deltaX', in a finite-volume context
it is more appropriate to define it as 'Sum(phi)/V*deltaT' (where 'Sum'
is a sum over the cell's faces). Similarly, the finite-difference
Fourier number, 'kappa/rho/Cp*deltaT/deltaX^2', is more consistently
expressed for finite-volume as 'Sum(Sf*kappa*deltaX)/(V*rho*Cp)*deltaT'.
This makes the calculation of the diffusion number less sensitive to the
presence of small, poor quality faces, and therefore makes time-step
adjustment more robust on arbitrary polyhedral meshes.
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'
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.
foamToC: New run-time selection table of contents printing and interrogation utility
The new solver modules cannot provide the equivalent functionality of the -list
options available in the solver applications so foamToC has been developed as a
better, more general and flexible alternative, providing a means to print any or
all run-time selection tables in any or all libraries and search the tables for
any particular entries and print which library files the corresponding tables
are in, e.g.
foamToC -solver fluid -table fvPatchScalarField
Contents of table fvPatchScalarField, base type fvPatchField:
advective libfiniteVolume.so
calculated libfiniteVolume.so
codedFixedValue libfiniteVolume.so
codedMixed libfiniteVolume.so
compressible::alphatJayatillekeWallFunctionlibthermophysicalTransportModels.so
compressible::alphatWallFunction libthermophysicalTransportModels.so
compressible::thermalBaffle1D<eConstSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::thermalBaffle1D<ePowerSolidThermoPhysics>libthermophysicalTransportModels.so
compressible::turbulentTemperatureCoupledBaffleMixedlibthermophysicalTransportModels.so
compressible::turbulentTemperatureRadCoupledMixedlibthermophysicalTransportModels.so
.
.
.
foamToC -solver fluid -search compressible::alphatWallFunction
compressible::alphatWallFunction is in tables
fvPatchField
fvPatchScalarField libthermophysicalTransportModels.so
and the very useful -allLibs option allows ALL libraries to be searched to find
in which table and which library file a particular model in in for example:
foamToC -allLibs -search phaseTurbulenceStabilisation
Loading libraries:
libtwoPhaseSurfaceTension.so
libcv2DMesh.so
libODE.so
.
.
.
phaseTurbulenceStabilisation is in tables
fvModel libmultiphaseEulerFoamFvModels.so
Application
foamToC
Description
Run-time selection table of contents printing and interrogation.
The run-time selection tables are populated by the optionally specified
solver class and any additional libraries listed in the \c -libs option or
all libraries using the \c -allLibs option. Once populated the tables can
be searched and printed by a range of options listed below. Table entries
are printed with the corresponding library they are in to aid selection
and the addition of \c libs entries to ensure availability to the solver.
Usage
\b foamToC [OPTION]
- \par -solver \<name\>
Specify the solver class
- \par -libs '(\"lib1.so\" ... \"libN.so\")'
Specify the additional libraries to load
- \par -allLibs
Load all libraries
- \par switches,
List all available debug, info and optimisation switches
- \par all,
List the contents of all the run-time selection tables
- \par tables
List the run-time selection table names (this is the default action)
- \par table \<name\>
List the contents of the specified table or the list sub-tables
- \par search \<name\>
Search for and list the tables containing the given entry
- \par scalarBCs,
List scalar field boundary conditions (fvPatchField<scalar>)
- \par vectorBCs,
List vector field boundary conditions (fvPatchField<vector>)
- \par functionObjects,
List functionObjects
- \par fvModels,
List fvModels
- \par fvConstraints,
List fvConstraints
Example usage:
- Print the list of scalar boundary conditions (fvPatchField<scalar>)
provided by the \c fluid solver without additional libraries:
\verbatim
foamToC -solver fluid -scalarBCs
\endverbatim
- Print the list of RAS momentum transport models provided by the
\c fluid solver:
\verbatim
foamToC -solver fluid -table RAScompressibleMomentumTransportModel
\endverbatim
- Print the list of functionObjects provided by the
\c multicomponentFluid solver with the libfieldFunctionObjects.so
library:
\verbatim
foamToC -solver multicomponentFluid \
-libs '("libfieldFunctionObjects.so")' -functionObjects
\endverbatim
- Print a complete list of all run-time selection tables:
\verbatim
foamToC -allLibs -tables
or
foamToC -allLibs
\endverbatim
- Print a complete list of all entries in all run-time selection tables:
\verbatim
foamToC -allLibs -all
\endverbatim
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.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces denseParticleFoam and all the corresponding
tutorials have been updated and moved to
tutorials/modules/incompressibleDenseParticleFluid.
Class
Foam::solvers::incompressibleDenseParticleFluid
Description
Solver module for transient flow of incompressible isothermal fluids coupled
with particle clouds including the effect of the volume fraction of
particles on the continuous phase, with optional mesh motion and change.
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, constraining or limiting
the solution.
