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 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.
The input syntax of the heatTransfer and interRegionHeatTransfer
fvModels has been modified to make it more usable and consistent with
the rest of OpenFOAM.
The settings for area per unit volume (AoV) are no longer controlled by
the heat transfer coefficient model. Instead they belong to the fvModel
itself and are specified within the base fvModel's dictionary.
The heat transfer coefficient model has been renamed to
"heatTransferCoefficientModel" to better account for exactly what it
does. It is now selected using an entry called
"heatTransferCoefficientModel", rather than "type". As a sub-sub model,
"type" clashes with the outer fvModel's "type" entry unless a Coeffs
dictionary is used. This change has made the Coeffs sub-dictionary
optional, as it should be, unless model-specific keywords require
disambiguation.
A heat transfer coefficient model can now be specified as follows:
heatTransfer1
{
type heatTransfer;
heatTransferCoeffs
{
selectionMode all;
semiImplicit true;
Ta 298;
AoV 100;
heatTransferCoefficientModel variable; // constant, function1
constantCoeffs
{
htc 1000;
}
variableCoeffs
{
a 0.332;
b 0.5;
c 0.333333;
Pr 0.7;
L 0.1;
}
}
}
Alternatively, the coefficient sub-dictionaries can all be omitted,
giving the following syntax:
heatTransfer1
{
type heatTransfer;
selectionMode all;
semiImplicit true;
Ta 298;
AoV 100;
heatTransferCoefficientModel variable;
a 0.332;
b 0.5;
c 0.333333;
Pr 0.7;
L 0.1;
}
Two fvModels have been added, densityConstraintSource and
pressureConstraintSource, for constraining the density or pressure of
zero-dimensional cases. The constrained property's variation in time is
specified by means of a Function1.
The constraints are maintained by adding or removing an appropriate
amount of mass. Properties are added or removed with this mass at their
current values. Both constraints therefore represent uniform expansion
or contraction in an infinite space. In the case of the pressure
constraint, the compressibility is used to determine this amount of
mass, and in the case of non-linear equations of state iteration may be
necessary to enforce the constraint accurately.
These models can be used to extend the concept of a zero-dimensional
simulation to one that uniformly expands or contracts, or features a
mass source or sink.
Example specification of a time-varying density constraint, in
constant/fvModels:
densityConstraintSource1
{
type densityConstraintSource;
rho
{
type scale;
values
(
(0 1.16)
(1 1.16)
(1.1 2.02)
(10 2.02)
);
}
}
Example specification of a constant pressure constraint:
pressureConstraintSource1
{
type pressureConstraintSource;
p 1e5;
}
An example in which the pressure is constrained is provided. This
example shows the reaction of nc7h16, and duplicates the behaviour of
the corresponding chemFoam case.
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
This model applies a heat source. It requires either the power, Q, or
the power per unit volume, q, to be specified.
Example usage:
heatSource
{
type heatSource;
selectionMode cellSet;
cellSet heater;
Q 1e6;
}
This model represents volumetric heat exchange with a constant ambient
temperature, using an area per unit volume, and a heat transfer
coefficient. It utilises the same heat transfer coefficient modelling as
the equivalent inter-region option.
Example usage:
heatTransfer
{
type heatTransfer;
heatTransferCoeffs
{
selectionMode cellSet;
cellSet c0;
semiImplicit no;
Ta 300;
type constant;
AoV 200;
htc 10;
}
}
There is now just one inter-region heat transfer model, and heat
transfer coefficient models are selected as sub-models. This has been
done to permit usage of the heat transfer models in other contexts.
Example usage:
interRegionHeatTransfer
{
type interRegionHeatTransfer;
interRegionHeatTransferCoeffs
{
nbrRegion other;
interpolationMethod cellVolumeWeight;
master true;
semiImplicit no;
type constant;
AoV 200;
htc 10;
}
}
The new fvModels is a general interface to optional physical models in the
finite volume framework, providing sources to the governing conservation
equations, thus ensuring consistency and conservation. This structure is used
not only for simple sources and forces but also provides a general run-time
selection interface for more complex models such as radiation and film, in the
future this will be extended to Lagrangian, reaction, combustion etc. For such
complex models the 'correct()' function is provided to update the state of these
models at the beginning of the PIMPLE loop.
fvModels are specified in the optional constant/fvModels dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The new fvConstraints is a general interface to optional numerical constraints
applied to the matrices of the governing equations after construction and/or to
the resulting field after solution. This system allows arbitrary changes to
either the matrix or solution to ensure numerical or other constraints and hence
violates consistency with the governing equations and conservation but it often
useful to ensure numerical stability, particularly during the initial start-up
period of a run. Complex manipulations can be achieved with fvConstraints, for
example 'meanVelocityForce' used to maintain a specified mean velocity in a
cyclic channel by manipulating the momentum matrix and the velocity solution.
fvConstraints are specified in the optional system/fvConstraints dictionary and
backward-compatibility with fvOption is provided by reading the
constant/fvOptions or system/fvOptions dictionary if present.
The separation of fvOptions into fvModels and fvConstraints provides a rational
and consistent separation between physical and numerical models which is easier
to understand and reason about, avoids the confusing issue of location of the
controlling dictionary file, improves maintainability and easier to extend to
handle current and future requirements for optional complex physical models and
numerical constraints.
