Topology change occurs before the time-increment and hence the oldest time
field (old-time in the case of 1st order time schemes, old-old-time in the case
of 2nd-order time schemes) is not actually needed as it is replaced by the
current time-field after time-increment so there is no purpose to mapping this
field. However, it is necessary to keep track of the existence of the
oldest-time field to ensure the correct number of old-time fields are cached for
the time-scheme. This development allows fvMesh to delete the redundant
oldest-time fields in such a manner that GeometricField can reinstate them
correctly after time-increment which is more efficient and more reliable than
attempting to map them and done previously.
Additionally fvMesh movement, which occurs after time-increment, now ensure all
old-time fields are up-to-date before NCC stitcher mapping so that both fields
and their old-time values are mapped consistently. This removes the need for
old-time field caching calls in MapGeometricFields, fvMeshAdder and
fvMeshStitcher, thus simplifying the code and improving maintainability.
The mesh-to-mesh methods have been reorganised so that
cell-volume-weight specific functionality is not implemented in the base
method class. Normalisation has been delegated to the methods so that it
can be performed in a method-appropriate way. The public and protected
interface of the methods has been minimised and unused code has been
removed.
and demonstrates the wave being generated in a region adjacent to the outlet and
propagating upstream towards the inlet where it is damped by a damping region
and mesh expansion.
Description
Exponential square ramp function starting from 0 and increasing to 1 from \c
start over the \c duration and remaining at 1 thereafter:
\f[
value(t) = (e^(((t - start)/duration)^2) - 1)/(e - 1)
\f]
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.
