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.
This fvModel applies a volume source to the continuity equation and to
all field equations. It can be applied to incompressible solvers, such
as incompressibleFluid and incompressibleVoF. For compressible solvers,
use the massSource model instead.
If the volumetric flow rate is positive then user-supplied fixed
property values are introduced to the field equations. If the volumetric
flow rate is negative then properties are removed at their current
value.
Example usage:
volumeSource
{
type volumeSource;
select cellSet;
cellSet volumeSource;
volumetricFlowRate 1e-4;
fieldValues
{
U (10 0 0);
k 0.375;
epsilon 14.855;
}
}
If the volumetric flow rate is positive then values should be provided
for all solved for fields. Warnings will be issued if values are not
provided for fields for which transport equations are solved. Warnings
will also be issued if values are provided for fields which are not
solved for.
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.
This can be used identically to a standard Function1. In addition, it
also permits specification of the dimensions. This allows the dimensions
to be checked. It also permits unit conversions. For example:
<name>
{
type table;
// Dimensions
xDimensions [CAD]; // Optional. Argument dimensions/units.
// Here, this specifies coordinates are in
// crank angle degrees (available if using
// engine time).
dimensions [mm]; // Optional. Value dimensions/units.
// Here, values are in mm.
// Tablulated data
values
(
(0 0)
(60 12) // <-- i.e., 12 mm at 60 degrees
(180 20)
(240 8)
(360 0)
);
outOfBounds repeat;
}
This replaces TimeFunction1, as it allows per-function control over
whether the function is considered to be one of real-time or user-time.
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 model now takes a 'phase' keyword to specify to which phase of a
multiphase simulation it applies to. In order to transfer heat to
multiple phases, multiple models must be specified.
The computation of the current and total accumulated mass is now shared
across all zeroDimensionalMassSource models. So, multiple models can be
used simultaneously.
If a negative mass flow rate is specified, the mass source fvModel will
now remove mass by adding implicit sources to the transport equations.
Properties are thereby removed at their current value. This is stable,
and is analogous to a zero-gradient outlet boundary condition.
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.
Cell-to-cell interpolation has been moved to a hierarchy separate from
meshToMesh, called cellsToCells. The meshToMesh class is now a
combination of a cellsToCells object and multiple patchToPatch objects.
This means that when only cell-to-cell interpolation is needed a basic
cellsToCells object can be selected.
Cell-to-cell and vol-field-to-vol-field interpolation now has two well
defined sets of functions, with a clear distinction in how weights that
do not sum to unity are handled. Non-unity weights are either
normalised, or a left-over field is provided with which to complete the
weighted sum.
The left-over approach is now consistently applied in mapFieldsPar,
across both the internal and patch fields, if mapping onto an existing
field in the target case. Warning are now generated for invalid
combinations of settings, such as mapping between inconsistent meshes
without a pre-existing target field.
All mapping functions now take fields as const references and return tmp
fields. This avoids the pattern in which non-const fields are provided
which relate to the source, and at some point in the function transfer
to the target. This pattern is difficult to reason about and does not
provide any actual computational advantage, as the fields invariably get
re-allocated as part of the process anyway.
MeshToMesh no longer stores the cutting patches. The set of cutting
patches is not needed anywhere except at the point of mapping a field,
so it is now supplied to the mapping functions as an argument.
The meshToMesh topology changer no longer supports cutting patch
information. This did not previously work. Cutting patches either get
generated as calculated, or they require a pre-existing field to specify
their boundary condition. Neither of these options is suitable for a
run-time mesh change.
More code has been shared with patchToPatch, reducing duplication.
Replacing volRegion removes unnecessary functionality duplication and ensures
cell set selection is consistent between functionObjects, fvModels and
fvConstraints for user convenience and reducing the code maintenance overhead.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c select entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
select entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
select all;
// Apply within a given cellSet
select cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
select cellZone; // Optional
cellZone rotor;
// Apply in cells containing a list of points
select points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
The keyword 'select' is now used to specify the cell, face or point set
selection method consistently across all classes requiring this functionality.
'select' replaces the inconsistently named 'regionType' and 'selectionMode'
keywords used previously but backwards-compatibility is provided for user
convenience. All configuration files and tutorials have been updated.
Examples of 'select' from the tutorial cases:
functionObjects:
cellZoneAverage
{
type volFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeInterval 1;
fields (p);
select cellZone;
cellZone injection;
operation volAverage;
writeFields false;
}
#includeFunc populationBalanceSizeDistribution
(
name=numberDensity,
populationBalance=aggregates,
select=cellZone,
cellZone=outlet,
functionType=numberDensity,
coordinateType=projectedAreaDiameter,
allCoordinates=yes,
normalise=yes,
logTransform=yes
)
fvModel:
cylinderHeat
{
type heatSource;
select all;
q 5e7;
}
fvConstraint:
momentumForce
{
type meanVelocityForce;
select all;
Ubar (0.1335 0 0);
}
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 timeName() function simply returns the dimensionedScalar::name() which holds
the user-time name of the current time and now that timeName() is no longer
virtual the dimensionedScalar::name() can be called directly. The timeName()
function implementation is maintained for backward-compatibility.
alphaEff is now an internal field used only for the implicit energy correction
term, kappaEff, q and divq are the general and rational interface to thermal
transport.
XiFoam and PDRFoam now explicitly instantiate a unityLewisEddyDiffusivity
fluidThermophysicalTransportModel as the the unity Lewis number approximation is
hard-coded into the formulation of the energy/composition system.
Now that kappa, Cp and Cv fields are cached and Cpv returns either the Cp or Cv
field reference depending on the energy solved and thermal transport is now
fundamentally based on temperature rather energy gradients it is no longer
necessary or useful to provide an abstract function returning alphahe.
the new fluidThermophysicalTransportModel and solidThermophysicalTransportModel
are derived from thermophysicalTransportModel providing a consistent and unified
interface for heat transport within and between regions. Coupled and external
heat-transfer boundary conditions can now be written independent of the
thermophysical properties or transport modelling of the regions providing
greater flexibility, simpler code and reduces the maintenance overhead.
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
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.
Description
General cell set selection class for models that apply to sub-sets
of the mesh.
Currently supports cell selection from a set of points, a specified cellSet
or cellZone or all of the cells. The selection method can either be
specified explicitly using the \c selectionMode entry or inferred from the
presence of either a \c cellSet, \c cellZone or \c points entry. The \c
selectionMode entry is required to select \c all cells.
Usage
Examples:
\verbatim
// Apply everywhere
selectionMode all;
// Apply within a given cellSet
selectionMode cellSet; // Optional
cellSet rotor;
// Apply within a given cellZone
selectionMode cellZone; // Optional
cellSet rotor;
// Apply in cells containing a list of points
selectionMode points; // Optional
points
(
(2.25 0.5 0)
(2.75 0.5 0)
);
\endverbatim
Also used as the base-class for fvCellSet which additionally provides and
maintains the volume of the cell set.
