to avoid further confusion concerning the origin of the thermo and transport
data which is not that supplied with the GRI mechanism as the these simple test
cases is to demonstrate the integration of a complex mechanism with or without
TDAC and ISAT, not complex transport modelling.
The proposed change does not change the mixing rules and the default coefficient mixing approach does not
provide mixed properties consistent with the GRI specification. The purpose of these simple test cases
is to demonstrate the integration of a complex mechanism with or without TDAC and ISAT, not complex transport modelling.
A new tutorial is required to demonstrate the GRI 3.0 mechanism with complex transport properties.
This reverts commit 53f3bc6fdd.
With waveForcing waves can be generated with a domain by applying forcing to
both the phase-fraction and velocity fields rather than requiring that the waves
are introduced at an inlet. This provides much greater flexibility as waves can
be generated in any direction relative to the mean flow, obliquely or even
against the flow. isotropicDamping or verticalDamping can be used in
conjunction with waveForcing to damp the waves before they reach an outlet,
alternatively waveForcing can be used in regions surrounding a hull for example
to maintain far-field waves everywhere.
The tutorials/multiphase/interFoam/laminar/forcedWave tutorial case is provided
to demonstrate the waveForcing fvModel as an alternative to the wave inlet
boundary conditions used in the tutorials/multiphase/interFoam/laminar/wave
case.
Class
Foam::fv::waveForcing
Description
This fvModel applies forcing to the liquid phase-fraction field and all
components of the vector field to relax the fields towards those
calculated from the current wave distribution.
The forcing force coefficient \f$\lambda\f$ should be set based on the
desired level of forcing and the residence time the waves through the
forcing zone. For example, if waves moving at 2 [m/s] are travelling
through a forcing zone 8 [m] in length, then the residence time is 4 [s]. If
it is deemed necessary to force for 5 time-scales, then \f$\lambda\f$ should
be set to equal 5/(4 [s]) = 1.2 [1/s].
Usage
Example usage:
\verbatim
waveForcing1
{
type waveForcing;
libs ("libwaves.so");
liquidPhase water;
// Define the line along which to apply the graduation
origin (600 0 0);
direction (-1 0 0);
// // Or, define multiple lines
// origins ((600 0 0) (600 -300 0) (600 300 0));
// directions ((-1 0 0) (0 1 0) (0 -1 0));
scale
{
type halfCosineRamp;
start 0;
duration 300;
}
lambda 0.5; // Forcing coefficient
}
\endverbatim
Replacing the specific twoPhaseChangeModel with a consistent and general fvModel
interface will support not just cavitation using the new compressible
VoFCavitation fvModel but also other phase-change and interface manipulation
models in the future and is easier to use for case-specific and other user
customisation.
Class
Foam::fv::compressible::VoFCavitation
Description
Cavitation fvModel
Usage
Example usage:
\verbatim
VoFCavitation
{
type VoFCavitation;
libs ("libcompressibleVoFCavitation.so");
model SchnerrSauer;
KunzCoeffs
{
pSat 2300; // Saturation pressure
UInf 20.0;
tInf 0.005; // L = 0.1 m
Cc 1000;
Cv 1000;
}
MerkleCoeffs
{
pSat 2300; // Saturation pressure
UInf 20.0;
tInf 0.005; // L = 0.1 m
Cc 80;
Cv 1e-03;
}
SchnerrSauerCoeffs
{
pSat 2300; // Saturation pressure
n 1.6e+13;
dNuc 2.0e-06;
Cc 1;
Cv 1;
}
}
\endverbatim
The cavitating ballValve tutorial has been updated to use the new VoFCavitation
fvModel.
Replacing the specific twoPhaseChangeModel with a consistent and general fvModel
interface will support not just cavitation using the new VoFCavitation fvModel
but also other phase-change and interface manipulation models in the future and
is easier to use for case-specific and other user customisation.
Corrects granular phase heat transfer in cases where eddy diffusivity based
thermophysical transport models are used.
Patch contributed by VTT Technical Research Centre of Finland.
The implementation of the porous baffle pressure-drop is explicit which can
cause instability and even negative pressure if there is rapid variation is flow
in conjunction with high porosity drag coefficients. This instability may be
moderated or eliminated by the application of sufficient relaxation of the
pressure-drop using the new optional relaxation factor:
Description
This boundary condition provides a jump condition, using the \c cyclic
condition as a base.
The porous baffle introduces a pressure jump defined by:
\f[
\Delta p = -(D \mu U + 0.5 I \rho |U|^2 )L
\f]
where
\vartable
p | pressure [Pa]
\rho | density [kg/m^3]
\mu | laminar viscosity [Pa s]
D | Darcy coefficient
I | inertial coefficient
L | porous media length in the flow direction
\endvartable
Usage
\table
Property | Description | Required | Default value
patchType | underlying patch type should be \c cyclic| yes |
phi | flux field name | no | phi
rho | density field name | no | rho
D | Darcy coefficient | yes |
I | inertial coefficient | yes |
length | porous media length in the flow direction | yes |
relaxation | Relaxation factor for pressure jump | no | 1
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type porousBafflePressure;
patchType cyclic;
jump uniform 0;
D 0.001;
I 1000000;
length 0.1;
relaxation 0.2;
value uniform 0;
}
\endverbatim
Note:
The underlying \c patchType should be set to \c cyclic
rather than p_rgh which introduces an imbalance between the pressure and
buoyancy forces. The relaxation factor for p_rgh specified in fvSolution is
used to relax the net force as the intent is to relax the pressure and this
provides convenient usage and backwards-compatibility.
Optional relaxation for the thermodynamic pressure p is also available for case
this provides convergence benefit for steady cases by relaxing the pressure work
term is the energy equation.
Note these changes only relate to the operation of the isothermalFluid solver
module for buoyant cases.
This change makes particles distribute between processors along with
their containing cells. This might be necessary, for example, if the
chemistry solution is being load balanced, or the cells are being
continually re-decomposed due to dynamic refinement.
Whilst this adds load balancing *with* lagrangian, it does not
facilitate load balancing *of* lagrangian. That would also require the
implementation of a lagranian CPU load that the distributor would then
attempt to balance.
This reference represents unnecessary storage. The mesh can be obtained
from tracking data or passed to the particle evolution functions by
argument.
In addition, removing the mesh reference makes it possible to construct
as particle from an Istream without the need for an iNew class. This
simplifies stream-based transfer, and makes it possible for particles to
be communicated by a polyDistributionMap.
The clouds fvModel and all the clouds it creates now contain a full set
of mesh change hooks. Some of these ultimately result in
"NotImplemented" errors, but this is an area under active development
and support may be added in the near future.
In addition, the list of cloud names is now specified from within the
fvModel, using a "clouds" entry. If this entry is omitted then a single
cloud named "cloud" is assumed as before. An example fvModel
specification for multiple clouds might be as follows:
clouds
{
type clouds;
libs ("liblagrangianParcel.so" "liblagrangianParcelTurbulence.so");
clouds (coalCloud limestoneCloud); // <-- New entry. Replaces
// the constant/clouds
// file.
}
Lagrangian solvers that construct clouds explicitly now do so via a new
"parcelClouds" mesh object. This ensures that they, too, are correctly
modified as a result of mesh changes.
Neither mechanism now permits no clouds. If there is not a "clouds"
entry (clouds fvModel), or a constant/clouds file (lagrangian solvers),
and there is not a constant/cloudProperties file for the default cloud,
then an error will be generated. Previously the code executed the solver
with no clouds. Intentional usage of the fvModel or lagrangian solvers
without clouds is considered highly unlikely.
to regain the behaviour of rhoPimpleFoam in OpenFOAM-9 which is more robust than
the potentially more consistent and accurate flux correction approach in
OpenFOAM-10.
This allows for partial specialisation, so the different variants of the
global IO containers do not need the function to be overloaded for each
contained type. This also fixes an ommission in providing overloads of
these functions for some of the global IO containers.
Resolves bug report https://bugs.openfoam.org/view.php?id=3890
timeControl functionality is supported for both execution and writing but
previously only instantiated if the writeControl entry is present in the
functionObject dictionary, now it is also instantiated if only the
executeControl entry is present as the functionObject might only have execute
functionality.
This reduces duplication and inconsistency between the List, Field, Map,
and PtrList variants. It also allows for future extension to other
container types such as DynamicList.
The Fwd.H headers define the default template arguments. This means the
dynamic list/field can be forward declared without there being any
confusion with regards to the specification of these arguments.
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.
