The mappedPatchBase has been separated into a type which maps from
another patch (still called mappedPatchBase) and one that maps from
internal cell values (mappedInternalPatchBase). This prevents the user
needing to specify settings for mapping procedures that are not being
used, and potentially don't even make sense given the context in which
they are being applied. It also removes a lot of fragile logic and error
states in the mapping engine and its derivatives regarding the mode of
operation. Mapping from any face in the boundary is no longer supported.
Most region-coupling mapping patches are generated automatically by
utilities like splitMeshRegions and extrudeToRegionMesh. Cases which
create region-coupling mapped patches in this way will likely require no
modification.
Explicitly user-specified mapping will need modifying, however. For
example, where an inlet boundary is mapped to a downstream position in
order to evolve a developed profile. Or if a multi-region simulation is
constructed manually, without using one of the region-generating
utilities.
The available mapped patch types are now as follows:
- mapped: Maps values from one patch to another. Typically used for
inlets and outlets; to map values from an outlet patch to an inlet
patch in order to evolve a developed inlet profile, or to permit
flow between regions. Example specification in blockMesh:
inlet
{
type mapped;
neighbourRegion region0; // Optional. Defaults to the same
// region as the patch.
neighbourPatch outlet;
faces ( ... );
}
Note that any transformation between the patches is now determined
automatically. Alternatively, it can be explicitly specified using
the same syntax as for cyclic patches. The "offset" and "distance"
keywords are no longer used.
- mappedWall: As mapped, but treated as a wall for the purposes of
modelling (wall distance). No transformation. Typically used for
thermally coupling different regions. Usually created automatically
by meshing utilities. Example:
fluid_to_solid
{
type mappedWall;
neighbourRegion solid;
neighbourPatch solid_to_fluid;
method intersection; // The patchToPatch method. See
// below.
faces ( ... );
}
- mappedExtrudedWall: As mapped wall, but with corrections to account
for the thickness of an extruded mesh. Used for region coupling
involving film and thermal baffle models. Almost always generated
automatically by extrudeToRegionMesh (so no example given).
- mappedInternal: Map values from internal cells to a patch. Typically
used for inlets; to map values from internal cells to the inlet in
order to evolve a developed inlet profile. Example:
inlet
{
type mappedInternal;
distance 0.05; // Normal distance from the patch
// from which to map cell values
//offset (0.05 0 0); // Offset from the patch from
// which to map cell values
faces ( ... );
}
Note that an "offsetMode" entry is no longer necessary. The mode
will be inferred from the presence of the distance or offset
entries. If both are provided, then offsetMode will also be required
to choose which setting applies.
The mapped, mappedWall and mappedExtrudedWall patches now permit
specification of a "method". This selects a patchToPatch object and
therefore determines how values are transferred or interpolated between
the patches. Valid options are:
- nearest: Copy the value from the nearest face in the neighbouring
patch.
- matching: As nearest, but with checking to make sure that the
mapping is one-to-one. This is appropriate for patches that are
identically meshed.
- inverseDistance: Inverse distance weighting from a small stencil of
nearby faces in the neighbouring patch.
- intersection: Weighting based on the overlapping areas with faces in
the neighbouring patch. Equivalent to the previous AMI-based mapping
mode.
If a method is not specfied, then the pre-existing approach will apply.
This should be equivalent to the "nearest" method (though in most such
cases, "matching" is probably more appropriate). This fallback may be
removed in the future once the patchToPatch methods have been proven
robust.
The important mapped boundary conditions are now as follows:
- mappedValue: Maps values from one patch to another, and optionally
modify the mapped values to recover a specified average. Example:
inlet
{
type mappedValue;
field U; // Optional. Defaults to the same
// as this field.
average (10 0 0); // The presence of this entry now
// enables setting of the average,
// so "setAverage" is not needed
value uniform 0.1;
}
- mappedInternalValue: Map values from cells to a patch, and
optionally specify the average as in mappedValue. Example:
inlet
{
type mappedValue;
field k; // Optional. Defaults to the same
// as this field.
interpolationScheme cell;
value uniform 0.1;
}
- mappedFlowRateVelocity: Maps the flow rate from one patch to
another, and use this to set a patch-normal velocity. Example:
inlet
{
type mappedFlowRate;
value uniform (0 0 0);
}
Of these, mappedValue and mappedInternalValue can override the
underlying mapped patch's settings by additionally specifying mapping
information (i.e., the neighbourPatch, offset, etc... settings usually
supplied for the patch). This also means these boundary condtions can be
applied to non-mapped patches. This functionality used to be provided
with a separate "mappedField" boundary condition, which has been removed
as it is no longer necessary.
Other mapped boundary conditions are either extremely niche (e.g.,
mappedVelocityFlux), are always automatically generated (e.g.,
mappedValueAndPatchInternalValue), or their usage has not changed (e.g.,
compressible::turbulentTemperatureCoupledBaffleMixed and
compressible::turbulentTemperatureRadCoupledMixed). Use foamInfo to
obtain further details about these conditions.
The calculation of alphat no longer depends upon the previous value of
alphat, so there is no longer any lagging, and iteration is not
necessary to recover the exact value specified by the wall function.
This completes the separation between thermodynamics and thermophysical
transport modelling and all models and boundary conditions involving heat
transfer now obtain the transport coefficients from the appropriate
ThermophysicalTransportModels rather than from fluidThermo.
This mode uses the patchToPatch system (the same one used by NCC) for
coupling two patches. It can be selected for a patch (e.g., in a
blockMeshDict) in the following way:
fluid_to_solid
{
type mappedWall;
sampleMode patchToPatch;
sampleRegion solid;
samplePatch solid_to_fluid;
patchToPatchMode intersection;
faces
(
(0 1 2 3)
...
);
}
The "patchToPatchMode" can be one of the following:
"intersection": Values obtained by weighting contributions from
sampled faces with the intersected area between the faces.
Equivalent to the nearestPatchFaceAMI sampleMode (which will be
removed in a future commit).
"inverseDistance": Values obtained by inverse-distance weighting
between a small stencil of nearby sampled faces.
"nearest": Take the value from the nearest sampled face.
"matching": As nearest, but with checks to ensure that the mapping
is one-to-one. To be used for mapping between identical patches.
The intention is that patchToPatch will become the only sampleMode, and
the four options above will become the options which determine how
mapping is performed. Cell-to-patch mapping will be transferred into a
separate class as its use cases essentially never intersect with those
of patch-to-patch mapping.
executed with foamRun for single region simulations of foamMultiRun for
multi-region simulations. Replaces compressibleInterFoam and all the
corresponding tutorials have been updated and moved to
tutorials/modules/compressibleVoF.
Class
Foam::solvers::compressibleVoF
Description
Solver module for for 2 compressible, non-isothermal immiscible fluids
using a VOF (volume of fluid) phase-fraction based interface capturing
approach, 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.
Either mixture or two-phase transport modelling may be selected. In the
mixture approach a single laminar, RAS or LES model is selected to model the
momentum stress. In the Euler-Euler two-phase approach separate laminar,
RAS or LES selected models are selected for each of the phases.
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
compressibleVoF.C
See also
Foam::solvers::fluidSolver
This greatly simplifies most setups in which it is a patch (or patches)
of the original mesh which are extruded. It prevents the need for a
topoSet configuration to convert the patch into a zone or set.
This is a better way of doing 3D thermal baffles. It does not require a
special region model and is consistent with multi-region handling in
other parts of OpenFOAM.
Poly patches should not hold non-uniform physical data that needs
mapping on mesh changes (decomposition, reconstruction, topology change,
etc ...). They should only hold uniform data that can be user-specified,
or non-uniform data that can be constructed on the fly from the poly
mesh.
With the recent changes to mappedPatchBase and extrudeToRegionMesh, this
has now been consistenly enforced, and a number of incomplete
implementations of poly patch mapping have therefore been removed.
An extruded region is now contiguous even when specified with multiple
face zones. Edges that border faces in different zones now extrude into
internal faces, rather than a pair of boundary faces. Different zones
now result only in different mapped patches in the extruded and primary
meshes. This means a mesh can be created for a single contiguous
extruded region spanning multiple patches. This might be necessary if,
for example, a film region is needed across multiple walls with
differing thermal boundary conditions.
Disconnected extruded regions can still be constructed by running the
extrudeToRegionMesh utility muiliple times.
The mapped patches created to couple the extruded regions now have
symmetric names similar to those created by splitMeshRegions. For
example, if the mapped patch in the primary region is called
"region0_to_extrudedRegion_f0", then the corresponding patch in the
extruded region is called "extrudedRegion_to_region0_f0" (f0, in this
example is the face zone from which the region was extruded).
Offsetting of the top patch is now handled automatically by a new
mappedExtrudedWallPolyPatch. This refers to the bottom patch and
automatically calculates the sampling offsets by doing a wave across the
extruded mesh layers. This prevents the need to store the offsets in the
patch itself, and makes it possible for the patch to undergo mesh
changes without adding additional functions to the polyPatch (mapping
constructors, autoMap and rmap methods, etc ...).
The typedName functions prepend the typeName to the object/field name to make a
unique name within the context of model or type.
Within a type which includes a typeName the typedName function can be called
with just the name of the object, e.g. within the kEpsilon model
typeName("G")
generates the name
kEpsilon:G
To create a typed name within another context the type name can be obtained from
the type specified in the function instantiation, e.g.
Foam::typedName<viscosityModel>("nu")
generates the name
viscosityModel:nu
This supersedes the modelName functionality provided in IOobject which could
only be used for IOobjects which provide the typeName, whereas typedName can be
used for any type providing a typeName.
A readUpdate should change face and point instances, but it should not
set the mesh data to be written. Any mesh change as a result of
readUpdate is the result of a read from disk, so it is not necessary for
that change to be written out.
Mapping with interpolation now behaves correctly when a single cell maps
to multiple faces. In addition, the mapping structure is more compact
and no longer results in copies being made of entire internal fields.
This has been achieved by rewriting the mapping strategy in
mappedPatchBase so that it maps from a reduced set of sampling locations
to the patch faces, rather than directly from the cells/faces to the
patch faces. This is more efficient, but it also permits multiple
sampling locations to be sent to a single cell/face. Values can then be
interpolated to these points before being sent back to the patch faces.
Previously a single cell/face could only be sent a single location onto
which to interpolate; typically that of the first associated patch face.
The resulting interpolated value was then sent back to all associated
patch faces. This meant that some (potentially most) patch faces did
receive a value interpolated to the correct position.
This is a very silly decomposition method that is useful for very
thoroughly testing parallelised functionality. It is absolutely not a
valid choice for any use case other than testing and debugging.
Population balance models now own their mass transfer rates, rather than
taking a non-constant reference to rates held by the phase system. This
means that they cannot reset or modify rates that relate to other
population balances.
