The fvModels directory has been reorganised into separate libraries to make it
easier to add and maintain new complex models such as the propellerDisk.
Class
Foam::fv::propellerDisk
Description
Disk momentum source which approximates a propeller based on a given
propeller curve.
Reference:
\verbatim
Hough, G. R., & Ordway, D. E. (1964).
The generalized actuator disk.
Developments in theoretical and applied mechanics, 2, 317-336.
\endverbatim
Usage
Example usage:
\verbatim
diskSource
{
type propellerDisk;
selectionMode cellZone;
cellZone propeller;
diskNormal (1 0 0); // Normal direction of the disk
n 26.03; // Rotation speed [1/s]
dPropeller 0.203; // Propeller diameter
dHub 0.039179; // Hub diameter
propellerCurve
{
type table;
// J Kt Kq
values
(
(0.10 (0.3267 0.03748))
(0.15 (0.3112 0.03629))
(0.20 (0.2949 0.03500))
(0.25 (0.2777 0.03361))
(0.30 (0.2598 0.03210))
(0.35 (0.2410 0.03047))
(0.40 (0.2214 0.02871))
(0.45 (0.2010 0.02682))
(0.50 (0.1798 0.02479))
(0.55 (0.1577 0.02261))
(0.60 (0.1349 0.02027))
(0.65 (0.1112 0.01777))
(0.70 (0.0867 0.01509))
(0.75 (0.0614 0.01224))
(0.80 (0.0353 0.00921))
);
}
}
\endverbatim
The distributions have been extended in various ways to permit usage in
a greater variety of situations...
The distributions now have write methods which allow a distribution to
be written into a field file for restart, therby permitting their usage
in boundary conditions and similar. Their read methods now also support
dimension-checked unit conversions for all their parameters.
An additional selector has been added that allows a distribution to be
re-constructed with a different sample size exponent.
The distributions now own their random generator, thereby simplifying
their usage and preventing the need for a (potentially dangling)
reference member. This makes sense now as the random generators do not
rely on global state; individual sub-models can and should own their own
random generator and manage its initialisation and restart. This
principle should be extended to other parts of the code in future.
The majority of input parameters now support automatic unit conversion.
Units are specified within square brackets, either before or after the
value. Primitive parameters (e.g., scalars, vectors, tensors, ...),
dimensioned types, fields, Function1-s and Function2-s all support unit
conversion in this way.
Unit conversion occurs on input only. OpenFOAM writes out all fields and
parameters in standard units. It is recommended to use '.orig' files in
the 0 directory to preserve user-readable input if those files are being
modified by pre-processing applications (e.g., setFields).
For example, to specify a volumetric flow rate inlet boundary in litres
per second [l/s], rather than metres-cubed per second [m^3/s], in 0/U:
boundaryField
{
inlet
{
type flowRateInletVelocity;
volumetricFlowRate 0.1 [l/s];
value $internalField;
}
...
}
Or, to specify the pressure field in bar, in 0/p:
internalField uniform 1 [bar];
Or, to convert the parameters of an Arrhenius reaction rate from a
cm-mol-kcal unit system, in constant/chemistryProperties:
reactions
{
methaneReaction
{
type irreversibleArrhenius;
reaction "CH4^0.2 + 2O2^1.3 = CO2 + 2H2O";
A 6.7e12 [(mol/cm^3)^-0.5/s];
beta 0;
Ea 48.4 [kcal/mol];
}
}
Or, to define a time-varying outlet pressure using a CSV file in which
the pressure column is in mega-pascals [MPa], in 0/p:
boundaryField
{
outlet
{
type uniformFixedValue;
value
{
type table;
format csv;
nHeaderLine 1;
units ([s] [MPa]); // <-- new units entry
columns (0 1);
mergeSeparators no;
file "data/pressure.csv";
outOfBounds clamp;
interpolationScheme linear;
}
}
...
}
(Note also that a new 'columns' entry replaces the old 'refColumn' and
'componentColumns'. This is is considered to be more intuitive, and has
a consistent syntax with the new 'units' entry. 'columns' and
'componentColumns' have been retained for backwards compatibility and
will continue to work for the time being.)
Unit definitions can be added in the global or case controlDict files.
See UnitConversions in $WM_PROJECT_DIR/etc/controlDict for examples.
Currently available units include:
Standard: kg m s K kmol A Cd
Derived: Hz N Pa J W g um mm cm km l ml us ms min hr mol
rpm bar atm kPa MPa cal kcal cSt cP % rad rot deg
A user-time unit is also provided if user-time is in operation. This
allows it to be specified locally whether a parameter relates to
real-time or to user-time. For example, to define a mass source that
ramps up from a given engine-time (in crank-angle-degrees [CAD]) over a
duration in real-time, in constant/fvModels:
massSource1
{
type massSource;
points ((1 2 3));
massFlowRate
{
type scale;
scale linearRamp;
start 20 [CAD];
duration 50 [ms];
value 0.1 [g/s];
}
}
Specified units will be checked against the parameter's dimensions where
possible, and an error generated if they are not consistent. For the
dimensions to be available for this check, the code requires
modification, and work propagating this change across OpenFOAM is
ongoing. Unit conversions are still possible without these changes, but
the validity of such conversions will not be checked.
Units are no longer permitted in 'dimensions' entries in field files.
These 'dimensions' entries can now, instead, take the names of
dimensions. The names of the available dimensions are:
Standard: mass length time temperature
moles current luminousIntensity
Derived: area volume rate velocity momentum acceleration density
force energy power pressure kinematicPressure
compressibility gasConstant specificHeatCapacity
kinematicViscosity dynamicViscosity thermalConductivity
volumetricFlux massFlux
So, for example, a 0/epsilon file might specify the dimensions as
follows:
dimensions [energy/mass/time];
And a 0/alphat file might have:
dimensions [thermalConductivity/specificHeatCapacity];
*** Development Notes ***
A unit conversion can construct trivially from a dimension set,
resulting in a "standard" unit with a conversion factor of one. This
means the functions which perform unit conversion on read can be
provided dimension sets or unit conversion objects interchangeably.
A basic `dict.lookup<vector>("Umean")` call will do unit conversion, but
it does not know the parameter's dimensions, so it cannot check the
validity of the supplied units. A corresponding lookup function has been
added in which the dimensions or units can be provided; in this case the
corresponding call would be `dict.lookup<vector>("Umean", dimVelocity)`.
This function enables additional checking and should be used wherever
possible.
Function1-s and Function2-s have had their constructors and selectors
changed so that dimensions/units must be specified by calling code. In
the case of Function1, two unit arguments must be given; one for the
x-axis and one for the value-axis. For Function2-s, three must be
provided.
In some cases, it is desirable (or at least established practice), that
a given non-standard unit be used in the absence of specific
user-defined units. Commonly this includes reading angles in degrees
(rather than radians) and reading times in user-time (rather than
real-time). The primitive lookup functions and Function1 and Function2
selectors both support specifying a non-standard default unit. For
example, `theta_ = dict.lookup<scalar>("theta", unitDegrees)` will read
an angle in degrees by default. If this is done within a model which
also supports writing then the write call must be modified accordingly
so that the data is also written out in degrees. Overloads of writeEntry
have been created for this purpose. In this case, the angle theta should
be written out with `writeEntry(os, "theta", unitDegrees, theta_)`.
Function1-s and Function2-s behave similarly, but with greater numbers
of dimensions/units arguments as before.
The non-standard user-time unit can be accessed by a `userUnits()`
method that has been added to Time. Use of this user-time unit in the
construction of Function1-s should prevent the need for explicit
user-time conversion in boundary conditions and sub-models and similar.
Some models might contain non-typed stream-based lookups of the form
`dict.lookup("p0") >> p0_` (e.g., in a re-read method), or
`Umean_(dict.lookup("Umean"))` (e.g., in an initialiser list). These
calls cannot facilitate unit conversion and are therefore discouraged.
They should be replaced with
`p0_ = dict.lookup<scalar>("p0", dimPressure)` and
`Umean_(dict.lookup<vector>("Umean", dimVelocity))` and similar whenever
they are found.
Corrected according to the original reference:
Marschall, H. (2011).
Towards the numerical simulation of multi-scale two-phase flows.
PhD Thesis, TU München.
The syntax of this model has changed to permit transfers of species in
either direction. A list of transferring species is now given for each
phase, rather than identifying a single reacting phase. For example:
phaseTransfer
(
vapour_particles
{
type reactionDriven;
// TiO2 and TiO2_s are created by reactions in the vapour
// and are then transferred to the particles
species.vapour (TiO2 TiO2_s);
// H2O is created by reactions in the particles and is then
// transferred to the vapour
species.particles (H2O);
}
);
These models represent a phase nucleating directly out of a
multi-component mixture into isolated particles (i.e., homogeneous),
rather than onto an existing surface or impurity (heterogeneous).
The homogeneousCondensation model can represent the initial stages of a
gas condensing into a liquid. Example usage, in constant/fvModels:
homogeneousCondensation
{
type homogeneousCondensation;
libs ("libmultiphaseEulerFvModels.so");
// Phases between which the transfer occurs. The first phase is the
// gas, and the second is the condensed liquid.
phases (gas water);
// The specie that is condensing
specie H2O;
// Linearise the latent heat contribution into the energy equation?
energySemiImplicit no;
// Saturation curve for the specie in the gaseous phase
pSat ArdenBuck;
}
The homogeneousLiquidPhaseSeparation model can represent the initial
stages of a liquid solution precipitating out a solid or separating into
two immiscible liquid phases: Example usage, in constant/fvModels:
homogeneousLiquidPhaseSeparation
{
type homogeneousLiquidPhaseSeparation;
libs ("libmultiphaseEulerFvModels.so");
// Phases between which the transfer occurs. The first phase is the
// solution, and the second is the precipitate.
phases (liquid sugar);
// The specie that is condensing
specie C2H12O6;
// Linearise the latent heat contribution into the energy equation?
energySemiImplicit no;
// Solubility given in mass of solute per mass of solvent
solubility constant 0.9;
}
If population balance is being used, then both of these models require a
source term to be applied to the size-group equations. This is achieved
by means of a new nucleationSizeGroup field source. Example usage, in
0/fDefault.water:
sources
{
homogeneousCondensation
{
type nucleationSizeGroup;
libs ("libmultiphaseEulerFvModels.so");
}
}
Functions have been added to populationBalance to generate the
volumetric allocation coefficient etaV. This is needed if a volume or
mass source is to be conveniently distributed into the size groups. The
number-based allocation coefficient, eta, is still available and is
still used in all cases within populationBalance.
The allocation bounds handling has been removed. This, as it turns out,
was just an incomplete subset of having both number- and volume-based
allocation coefficients implemented.
A new nonConformalMappedWall patch type has been added which can couple
between different regions of a multi-region simulation. This patch type
uses the same intersection algorithm as the nonConformalCyclic patch,
which is used for coupling sections of a mesh within the same region.
The nonConformalMappedWall provides some advantages over the existing
mappedWall patches:
- The connection it creates is not interpolative. It creates a pair of
coupled finite-volume faces wherever two opposing faces overlap.
There is therefore no interpolation error associated with mapping
values across the coupling.
- Faces (or parts of faces) which do not overlap are not normalised
away by an interpolation or averaging process. Instead, they are
assigned an alternative boundary condition; e.g., an external
constraint, or even another non-conformal cyclic or mapped wall.
This makes the system able to construct partially-overlapping
couplings.
- The direct non-interpolative transfer of values between the patches
makes the method equivalent to a conformal coupling. Properties of
the solution algorithm, such as conservation and boundedness, are
retained regardless of the non-conformance of the boundary meshes.
- All constructed finite volume faces have accurate centre points.
This makes the method second order accurate in space.
Usage:
Non-conformal mapped wall couplings are constructed as the last stage of
a multi-region meshing process. First, a multi-region mesh is
constructed in one of the usual ways, but with the boundaries specified
as standard non-coupled walls instead of a special mapped type. Then,
createNonConformalCouples is called to construct non-conformal mapped
patches that couple overlapping parts of these non-coupled walls. This
process is very similar to the construction of non-conformal cyclics.
createNonConformalCouples requires a
system/createNonConformalCouplesDict in order to construct non-conformal
mapped walls. Each coupling is specified in its own sub-dictionary, and
a "regions" entry is used to specify the pair of regions that the
non-conformal mapped wall will couple. Non-conformal cyclics can also be
created using the same dictionary, and will be assumed if the two
specified regions are the same, or if a single "region" entry is
specified. For example:
// Do not modify the fields
fields no;
// List of non-conformal couplings
nonConformalCouples
{
// Non-conformal cyclic interface. Only one region is specified.
fluidFluid
{
region fluid;
originalPatches (nonCoupleRotating nonCoupleStationary);
}
// Non-conformal mapped wall interface. Two different regions
// have been specified.
fluidSolid
{
regions (fluid solid);
originalPatches (nonCoupleRotating nonCoupleStationary);
}
}
After this step, a case should execute with foamMultiRun and decompose
and reconstruct and post-process normally.
One additional restriction for parallelised workflows is that
decomposition and reconstruction must be done with the -allRegions
option, so that the both sides of the coupling are available to the
decomposition/reconstruction algorithm.
Tutorials:
Two tutorials have been added to demonstrate use of this new
functionality:
- The multiRegion/CHT/misalignedDuct case provides a simple visual
confirmation that the patches are working (the exposed corners of
the solid will be hot if the non-conformal mapped walls are active),
and it demonstrates createNonConformalCouples's ability to add
boundary conditions to existing fields.
- The multiRegion/CHT/notchedRoller case demonstrates use of
non-conformal mapped walls with a moving mesh, and also provides an
example of parallelised usage.
Notes for Developers:
A coupled boundary condition now uses a new class,
mappedFvPatchBaseBase, in order to perform a transfer of values to or
from the neighbouring patch. For example:
// Cast the patch type to it's underlying mapping engine
const mappedFvPatchBaseBase& mapper =
mappedFvPatchBaseBase::getMap(patch());
// Lookup a field on the neighbouring patch
const fvPatchScalarField& nbrTn =
mapper.nbrFvPatch().lookupPatchField<volScalarField, scalar>("T");
// Map the values to this patch
const scalarField Tn(mapper.fromNeighbour(nbrTn));
For this to work, the fvPatch should be of an appropriate mapped type
which derives from mappedFvPatchBaseBase. This mappedFvPatchBaseBase
class provides an interface to to both conformal/interpolative and
non-conformal mapping procedures. This means that a coupled boundary
condition implemented in the manner above will work with either
conformal/interpolative or non-conformal mapped patch types.
Previously, coupled boundary conditions would access a mappedPatchBase
base class of the associated polyPatch, and use that to transfer values
between the patches. This direct dependence on the polyPatch's mapping
engine meant that only conformal/interpolative fvPatch fields that
corresponded to the polyPatch's geometry could be mapped.
Now that BasicThermo::Cp returns a volScalarField reference because Cp is cached
in BasicThermo code calling Cp can hold a reference rather than a copy for
efficiency.
The Clang compiler does not use std::move to transfer the result of the ternary
operator into the phase-fraction field resulting in it not being registered to
the database. To work around this limitation/bug the ternary operator is now
provided with tmp fields the result of which is passed with an IOobject to the
final field constructor to ensure it is registered and the IO options set
correctly.
An enumeration has been added to the arguments of the allocation
coefficient function, eta, to allow specification of how to allocate out
of bounds of the population balance size-groups. There are two options:
- "Clamp" will create an out-of-bounds allocation coefficient of exactly
one. This partitions unity across all size-space.
- "Extrapolate" will create an out-of-bounds allocation coefficient in
proportion to the ratio between the given size and the nearest
size-group size. This does not partition unity outside the range of
the size-groups.
The previous operation is equivalent to "Extrapolate".
It is not yet clear which method is preferable and under what
circumstances. More testing is required. The enumeration has been
created to facilitate this testing.
The specie molecular mass (Wi) and formation enthalpy (hfi) methods now
return dimensioned scalars. This permits their direct inclusion into
dimensioned field expressions. Non-dimensioned methods have been
retained with a "Value" suffix (i.e., WiValue and hfiValue).
All property functions in the low-level templated thermo property
implementations and the high-level virtual interfaces have been made
consistent. All energies and enthalpies are lower case to denote that
they are specific quantities. Molar functions have been removed as these
are no longer used anywhere.
The nearWallDist MeshObject is now deleted on mesh-change rather than updated
which is more efficient for cases with multiple mesh changes, e.g. motion,
stitching and mapping by avoiding unnecessary updates.
As a consequence of this change the wallDist::y() volScalarField reference
should not be cached across mesh changes so the turbulence models now obtain the
y field as required from the new momentumTransportModel::y() function, the
original near-wall distance function is now named momentumTransportModel::yb()
to clarify that it is the wall distance of the boundary cells.
This is consistent with the fluid solvers, and prevents failures
associated with using fields that haven't yet been updated or corrected
following mesh changes
This simple model creates a heat transfer coefficient in proportion with
the corresponding drag model's momentum transfer coefficient. A
user-defined Prandtl number and a harmonic average of the phases'
specific heats are used to specify the constant of proportionality.
This model has no physical basis. It exists primarily for testing
purposes. It has the advantage of being applicable to any interface,
including those representing segregated configurations.
Example usage:
heatTransfer
{
gas_segregatedWith_liquid
{
type Prandtl;
Pr 0.7;
}
}
The patch-specific mapper interfaces, fvPatchFieldMapper and
pointPatchFieldMapper, have been removed as they did not do anything.
Patch mapping constructors and functions now take a basic fieldMapper
reference.
An fvPatchFieldMapper.H header has been provided to aid backwards
compatability so that existing custom boundary conditions continue to
compile.
Currently in compressibleVoF vDot contains only the compressibility dilatation
effect whereas in multiphaseEuler the effect of sources are also included but
this will be refactored shortly so that the handling of mass sources and
compressibility is consistent between VoF and Euler-Euler solvers.
The previously hard-coded 1e-4 division stabilisation used when linearising vDot
for bounded semi-implicit solution of the phase-fractions is now an optional
user-input with keyword vDotResidualAlpha, e.g. in multiphaseEuler:
solvers
{
"alpha.*"
{
nAlphaCorr 1;
nAlphaSubCycles 2;
vDotResidualAlpha 1e-6;
}
.
.
.
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.
IsothermalSolidPhaseModel does not update energy and density from pressure
whereas IsothermalPhaseModel does to allow compressible fluid phases to change
volume due to pressure changes.
