This simple model generates a phase change between two phases calculated
from the following expression:
\dot{m}/V = C \alpha \grad \alpha
Where:
\dot{m}/V | mass transfer rate per unit volume
C | coefficient
\alpha | volume fraction of the source phase
Example usage:
coefficientPhaseChange
{
type coefficientPhaseChange;
phases (liquid vapour);
C [kg/m^2/s] 0.1;
}
This model may be of use in simple situations, but it is primarily
designed to serve as a prototype for more complex and physical
mechanisms of phase changes.
The fact that these names create sources in their associated transport
equations is clear in context, so the name does not need to contain
'Source'.
Having 'Source' in the name is a historic convention that dates back to
when fvModels and fvConstraints were combined in a single fvOptions
interface. In this interface, disambiguation between sources and
constraints was necessary.
The full set of name changes is as follows:
accelerationSource -> acceleration
actuationDiskSource -> actuationDisk
effectivenessHeatExchangerSource -> effectivenessHeatExchanger
explicitPorositySource -> porosityForce
radialActuationDiskSource -> radialActuationDisk
rotorDiskSource -> rotorDisk
sixDoFAccelerationSource -> sixDoFAcceleration
solidEquilibriumEnergySource -> solidThermalEquilibrium
solidificationMeltingSource -> solidificationMelting
volumeFractionSource -> volumeBlockage
interRegionExplicitPorositySource -> interRegionPorosityForce
VoFSolidificationMeltingSource -> VoFSolidificationMelting
The old names are still available for backwards compatibility.
This simple model generates a mass transfer between two phases
calculated from the following expression:
\dot{m}/V = C \alpha \grad \alpha
Where:
\dot{m}/V | mass transfer rate per unit volume
C | coefficient
\alpha | volume fraction of the source phase
Example usage:
coefficientMassTransfer
{
type coefficientMassTransfer;
phases (liquid vapour);
C [kg/m^2/s] 0.1;
}
This model may be of use in simple situations, but it is primarily
designed to serve as a prototype for more complex and physical
mechanisms of mass transfer between phases.
When an fvModel source introduces fluid into a simulation it should also
create a corresponding source term for all properties transported into
the domain by that injection. The source is, effectively, an alternative
form of inlet boundary, on which all transported properties need an
inlet value specified.
These values are now specified in the property field files. The
following is an example of a 0/U file in which the velocity of fluid
introduced by a fvModel source called "injection1" is set to a fixed
value of (-1 0 0):
dimensions [0 1 -1 0 0 0 0];
internalField uniform (0 0 0);
boundaryField
{
#includeEtc "caseDicts/setConstraintTypes"
wall
{
type noSlip;
}
atmosphere
{
type pressureInletOutletVelocity;
value $internalField;
}
}
// *** NEW ***
sources
{
injection1
{
type uniformFixedValue;
uniformValue (-1 0 0);
}
}
And the following entry in the 0/k file specifies the turbulent kinetic
energy introduced as a fraction of the mean flow kinetic energy:
sources
{
injection1
{
type turbulentIntensityKineticEnergy;
intensity 0.05;
}
}
The specification is directly analogous to boundary conditions. The
conditions are run-time selectable and can be concisely implemented.
They can access each other and be inter-dependent (e.g., the above,
where turbulent kinetic energy depends on velocity). The syntax keeps
field data localised and makes the source model (e.g., massSource,
volumeSource, ...) specification independent from what other models and
fields are present in the simulation. The 'fieldValues' entry previously
required by source models is now no longer required.
If source values need specifying and no source condition has been
supplied in the relevant field file then an error will be generated.
This error is similar to that generated for missing boundary conditions.
This replaces the behaviour where sources such as these would introduce
a value of zero, either silently or with a warning. This is now
considered unacceptable. Zero might be a tolerable default for certain
fields (U, k), but is wholly inappropriate for others (T, epsilon, rho).
This change additionally makes it possible to inject fluid into a
multicomponent solver with a specified temperature. Previously, it was
not possible to do this as there was no means of evaluating the energy
of fluid with the injected composition.
The interface for fvModels has been modified to improve its application
to "proxy" equations. That is, equations that are not straightforward
statements of conservation laws in OpenFOAM's usual convention.
A standard conservation law typically takes the following form:
fvMatrix<scalar> psiEqn
(
fvm::ddt(alpha, rho, psi)
+ <fluxes>
==
<sources>
);
A proxy equation, on the other hand, may be a derivation or
rearrangement of a law like this, and may be linearised in terms of a
different variable.
The pressure equation is the most common example of a proxy equation. It
represents a statement of the conservation of volume or mass, but it is
a rearrangement of the original continuity equation, and it has been
linearised in terms of a different variable; the pressure. Another
example is that in the pre-predictor of a VoF solver the
phase-continuity equation is constructed, but it is linearised in terms
of volume fraction rather than density.
In these situations, fvModels sources are now applied by calling:
fvModels().sourceProxy(<conserved-fields ...>, <equation-field>)
Where <conserved-fields ...> are (alpha, rho, psi), (rho, psi), just
(psi), or are omitted entirely (for volume continuity), and the
<equation-field> is the field associated with the proxy equation. This
produces a source term identical in value to the following call:
fvModels().source(<conserved-fields ...>)
It is only the linearisation in terms of <equation-field> that differs
between these two calls.
This change permits much greater flexibility in the handling of mass and
volume sources than the previous name-based system did. All the relevant
fields are available, dimensions can be used in the logic to determine
what sources are being constructed, and sources relating to a given
conservation law all share the same function.
This commit adds the functionality for injection-type sources in the
compressibleVoF solver. A following commit will add a volume source
model for use in incompressible solvers.
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;
}
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.
The previous fluidThermophysicalTransportModel typedef has been renamed
fluidThermoThermophysicalTransportModel as it is instantiated on fluidThermo,
freeing the name fluidThermophysicalTransportModel for the new base-class.
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
to provide a single consistent code and user interface to the specification of
physical properties in both single-phase and multi-phase solvers. This redesign
simplifies usage and reduces code duplication in run-time selectable solver
options such as 'functionObjects' and 'fvModels'.
* physicalProperties
Single abstract base-class for all fluid and solid physical property classes.
Physical properties for a single fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties' dictionary.
Physical properties for a phase fluid or solid within a region are now read
from the 'constant/<region>/physicalProperties.<phase>' dictionary.
This replaces the previous inconsistent naming convention of
'transportProperties' for incompressible solvers and
'thermophysicalProperties' for compressible solvers.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the
'physicalProperties' dictionary does not exist.
* phaseProperties
All multi-phase solvers (VoF and Euler-Euler) now read the list of phases and
interfacial models and coefficients from the
'constant/<region>/phaseProperties' dictionary.
Backward-compatibility is provided by the solvers reading
'thermophysicalProperties' or 'transportProperties' if the 'phaseProperties'
dictionary does not exist. For incompressible VoF solvers the
'transportProperties' is automatically upgraded to 'phaseProperties' and the
two 'physicalProperties.<phase>' dictionary for the phase properties.
* viscosity
Abstract base-class (interface) for all fluids.
Having a single interface for the viscosity of all types of fluids facilitated
a substantial simplification of the 'momentumTransport' library, avoiding the
need for a layer of templating and providing total consistency between
incompressible/compressible and single-phase/multi-phase laminar, RAS and LES
momentum transport models. This allows the generalised Newtonian viscosity
models to be used in the same form within laminar as well as RAS and LES
momentum transport closures in any solver. Strain-rate dependent viscosity
modelling is particularly useful with low-Reynolds number turbulence closures
for non-Newtonian fluids where the effect of bulk shear near the walls on the
viscosity is a dominant effect. Within this framework it would also be
possible to implement generalised Newtonian models dependent on turbulent as
well as mean strain-rate if suitable model formulations are available.
* visosityModel
Run-time selectable Newtonian viscosity model for incompressible fluids
providing the 'viscosity' interface for 'momentumTransport' models.
Currently a 'constant' Newtonian viscosity model is provided but the structure
supports more complex functions of time, space and fields registered to the
region database.
Strain-rate dependent non-Newtonian viscosity models have been removed from
this level and handled in a more general way within the 'momentumTransport'
library, see section 'viscosity' above.
The 'constant' viscosity model is selected in the 'physicalProperties'
dictionary by
viscosityModel constant;
which is equivalent to the previous entry in the 'transportProperties'
dictionary
transportModel Newtonian;
but backward-compatibility is provided for both the keyword and model
type.
* thermophysicalModels
To avoid propagating the unnecessary constructors from 'dictionary' into the
new 'physicalProperties' abstract base-class this entire structure has been
removed from the 'thermophysicalModels' library. The only use for this
constructor was in 'thermalBaffle' which now reads the 'physicalProperties'
dictionary from the baffle region directory which is far simpler and more
consistent and significantly reduces the amount of constructor code in the
'thermophysicalModels' library.
* compressibleInterFoam
The creation of the 'viscosity' interface for the 'momentumTransport' models
allows the complex 'twoPhaseMixtureThermo' derived from 'rhoThermo' to be
replaced with the much simpler 'compressibleTwoPhaseMixture' derived from the
'viscosity' interface, avoiding the myriad of unused thermodynamic functions
required by 'rhoThermo' to be defined for the mixture.
Same for 'compressibleMultiphaseMixture' in 'compressibleMultiphaseInterFoam'.
This is a significant improvement in code and input consistency, simplifying
maintenance and further development as well as enhancing usability.
Henry G. Weller
CFD Direct Ltd.
The MomentumTransportModels library now builds of a standard set of
phase-incompressible and phase-compressible models. This replaces most
solver-specific builds of these models.
This has been made possible by the addition of a new
"dynamicTransportModel" interface, from which all transport classes used
by the momentum transport models now derive. For the purpose of
disambiguation, the old "transportModel" has also been renamed
"kinematicTransportModel".
This change has been made in order to create a consistent definition of
phase-incompressible and phase-compressible MomentumTransportModels,
which can then be looked up by functionObjects, fvModels, and similar.
Some solvers still build specific momentum transport models, but these
are now in addition to the standard set. The solver does not build all
the models it uses.
There are also corresponding centralised builds of phase dependent
ThermophysicalTransportModels.
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.
