The flow rate to the disk is now (dHat & U_o) and the momentum source
orientation dHat where dHat is the unit disk direction (orientation).
Constant values for momentum source for actuation disk
\f[
T = 2 \rho A (\hat{d}\dot U_{o})^2 a (1-a) \hat{d}
\f]
where:
\vartable
A | Disk area
dHat | Unit disk direction
U_o | Upstream velocity
a | 1 - Cp/Ct
Cp | Power coefficient
Ct | Thrust coefficient
\endvartable
Alpha contact angle boundaries are now specified in the following way
for multiphase solvers (i.e., multiphaseInterFoam,
compressibleMultiphaseInterFoam, and multiphaseEulerFoam):
boundaryField
{
wall
{
type alphaContactAngle;
contactAngleProperties
{
water
{
// Constant contact angle
theta0 90;
}
oil
{
// Dynamic contact angle
theta0 90;
uTheta 1;
thetaA 125;
thetaR 85;
}
}
value uniform 0;
}
}
All solvers now share the same implementation of the alphaContactAngle
boundary condition and the contact angle correction algorithm.
If alpha contact angle boundary conditions are used they must be
specified for all phases or an error will result. The consistency of the
input will also be checked. The angles given for water in the alpha.air
file must be 180 degrees minus the angles given for air in the
alpha.water file.
When the optional tangentialVelocity is specified for the
pressureInletOutletVelocity it typically relates to a translating coordinate
transformation, e.g. for a towing-tank simulation, and does not contribute to
the real free-stream total-pressure. Thus in order to get better behaviour from
the totalPressure BC for reversing flow at an entrainment boundary with
tangentialVelocity specified this velocity is subtracted from the extrapolated
velocity when calculating the kinematic contribution to the total pressure.
Updated tutorials for the changes to the blending system. Cases using
"none" blending have been updated to use "continuous" or "segregated" as
appropriate.
The bed tutorial has been extended to include a proper switch to a bed
drag model (AttouFerschneider) when the solid phase displaces the
fluids. This change made the trickleBed case a subset of the bed case,
so the trickleBed has been removed.
Blending of sub-models has been extended so that it provides the
necessary functionality for the simulation of three or more phases.
Models now, by default, blend within the two-phase subset. So, the
functions which specify blending coefficients are evaluated using
`alpha1/(alpha1 + alpha2)` and `alpha2/(alpha1 + alpha2)`, rather than
just `alpha1` and `alpha2`. This ensures that the functions behave
consistently in multiphase configurations as the combined fraction of
both phases reduces.
Additional "displaced" categories of model are now available. These
allow the interface modelling to change as a third phase fraction
becomes significant and displaces the phases associated with the
interface in question. These can be specified using displaced phase
interfaces. If they are not supplied then the non-displaced models apply
instead.
Additional "general" categories are also now available. These span the
entire range of the subset's phase fraction space and apply if models
for the more specific configurations (i.e., displaced and segregated)
are omitted.
For example, to specify standard SchillerNaumann droplet/bubble drag
modelling outside of a solid bed, and the bed-specific AttouFerschneider
drag model within the bed, the following specification could be used:
drag
{
air_dispersedIn_water
{
type SchillerNaumann;
residualRe 1e-3;
}
water_dispersedIn_air
{
$air_dispersedIn_water;
}
air_water_displacedBy_solid
{
type AttouFerschneider;
gas air;
liquid water;
solid solid;
E1 280;
E2 4.8;
}
solid_dispersedIn_air
{
$air_water_displacedBy_solid;
}
solid_dispersedIn_water
{
$air_water_displacedBy_solid;
}
}
The "air_water_displacedBy_solid" model shown above is a
"general-displaced" model, in that its application does not depend on
dispersal of the air-water system; it only depends on the level of
displacement by the solid. Alternatively, a set of three
"dispersed-displaced" and "segregated-displaced" models could have been
provided with the following syntax:
air_dispersedIn_water_displacedBy_solid
{
...
}
air_segregatedWith_water_displacedBy_solid
{
...
}
water_dispersedIn_air_displacedBy_solid
{
...
}
The blending methods themselves have changed slightly. There are now two
new methods; "segregated" for churning configurations in which no phase
is ever considered dispersed in another, and "continuous" where a
specified phase is always considered to be continuous and all other
phases are considered dispersed. These models replace the "none" model.
The linear and hyperbolic blending methods now support a "none" entry,
which can be set for parameters for phases that cannot become
continuous. For example, in an air-water-particles simulation the air
and water may become continuous, but the particles may not. A suitable
linear blending specification for this scenario might be as follows:
blending
{
default
{
type linear;
minFullyContinuousAlpha.air 0.8;
minPartlyContinuousAlpha.air 0.2;
minFullyContinuousAlpha.water 0.8;
minPartlyContinuousAlpha.water 0.2;
minFullyContinuousAlpha.solid none;
minPartlyContinuousAlpha.solid none;
}
}
The blending now provides far more feedback in terms of warnings and
errors when invalid or inadvisable specifications are made.
It is now also possible to visualise the various models' utilisation of
the phase fraction space. If the keyword "format" is placed in the
blending section of constant/phaseProperties then a plot (1 or 2 phases)
or surface (3 or more phases) file will be written out which shows the
phase fractions and the coefficients with which various models are
combined.
These changes are not required for the cases to run with the new
phaseInterface system. The syntax prior to this commit will be read in
the new phaseInterface system's backwards compatibility mode.
A new class, phaseInterface, has been added to represent interfacial
configurations between pairs of phases. This class and its derivations
explicitly represent different configurations (e.g., dispersal,
segregation, displacement) by type and provide a run-time selection
mechanism so that these configurations can be uniquely named and
intuitively selected for sub-models to apply to.
For example, drag models can be selected for an air-water system with
full phase inversion with the following syntax in
constant/phaseProperties:
drag
{
air_dispersedIn_water
{
type IshiiZuber;
}
air_segregatedWith_water
{
type segregated;
m 0.5;
n 8;
}
steam_dispersedIn_water
{
type SchillerNaumann;
residualRe 1e-3;
}
}
As well as the entries now being underscore separated, note also that
the sub model sections are now dictionaries ("{ ... }"), rather than
lists ("( ... );"). If a list is provided instead, then the input will
be considered to be in the old syntax, and will be read in a backwards
compatibility mode.
The new dictionary syntax permits substitution and therefore reuse of
settings, reducing the workload associated with setting up a large case
with many model combinations. In future it may be possible to introduce
wildcards to further reduce the verbosity of the input.
The new phase-interface classes and keywords and the phase-pairs and
keywords that they replace are listed below:
Default/General: phaseInterface "<phase>_<phase>"
replaces phasePair "(<phase> and <phase>)"
Dispersed: dispersedPhaseInterface "<phase>_dispersedIn_<phase>"
replaces orderedPhasePair "(<phase> in <phase>)"
Segregated: segregatedPhaseInterface "<phase>_segregatedWith_<phase>"
replaces phasePair "(<phase> and <phase>)"
Sided: sidedPhaseInterface "<phase>_<phase>_inThe_<phase>"
replaces orderedPhasePair "(<phase> in <phase>)"
Displaced: displacedPhaseInterface "<phase>_<phase>_displacedBy_<phase>"
is new
Interface combinations are also possible. There can be, for example, an
interface which is both dispersed and sided. This class is the
dispersedSidedPhaseInterface and can be selected with the keyword
"<phase>_dispersedIn_<phase>_inThe_<phase>". This is needed, for
example, in two-resistance heat transfer modelling, where a different
model can be selected to represent heat transfer within the fluids on
either side of an interface.
A full list of all available phase interface relationships can be
generated by specifying an incorrect name, and viewing the output of the
error message that results.
The "displaced" interface is not currently used, but will shortly be
utilised to allowing the user to control how models between phases
change as the fraction of a third phase becomes significant and
displaces the phases associated with the interface in question.
Notes for developers:
There is no centralised storage of phase interface relationships in the
phase system any more; the table of phasePairs has been removed, and
there is no correcponding table of phaseInterfaces. Models now locally
store their own phaseInterface objects, or a derivation thereof, rather
than a reference to a centrally stored object. These phaseInterface
classes hold only references so there is no cost associated with their
duplication in multiple sub models.
If a model requires an interface of a specific type, it has to down-cast
the interface provided to it. There is a `phaseSystem::modelCast` method
for this purpose which also provides meaningful error messages in the
event that an inappropriate interface was specified and the cast fails.
Model generation is now hierarchical. Wrapper models (blended and sided)
are constructed with the same interface as non-wrapper models (drag,
virtual mass, etc...). The wrapper model constructors call the
constructors of their sub-models directly, rather than requiring model
pointers to be passed in.
Sub-model lookup has been significantly generalised and simplified.
There is now just one `phaseSystem::lookupInterfacialModel` method which
takes a phaseInterface as its argument. Looking up a model for a
specific configuration just requires providing the appropriate
phaseInterface. E.g., this call will return the virtual mass model for
gas bubbles in liquid:
lookupSubModel<virtualMassModel>(dispersedPhaseInterface(gas, liquid))
Whilst this call will return the drag model for the segregated regime:
lookupSubModel<dragModel>(segregatedPhaseInterface(phase1, phase2))
And this call will return the complete blended heat transfer model:
lookupSubModel<blendedHeatTransferModel>(phaseInterface(phase1, phase2))
This is useful for creating a UPtrList<BaseType> from a
UPtrList<DerivedType>, or creating a UPtrList<const Type> from a
UPtrList<Type>.
The new pointers are constructed by implicit conversion of the old ones,
so the new type must be a base class of the old type and it must not
remove const-ness.
currently without strain-rate dependency.
Class
Foam::mixtureViscosityModels::Quemada
Description
Quemada viscosity model for for colloidal dispersions.
References:
\verbatim
Quemada, D. (1998).
Rheological modelling of complex fluids. I.
The concept of effective volume fraction revisited.
The European Physical Journal-Applied Physics, 1(1), 119-127.
\endverbatim
Usage
Example usage:
\verbatim
viscosityModel Quemada;
alphaMax 0.6; // Maximum dispersed phase-fraction (packing fraction)
q 2; // Exponent, defaults to 2
rho 1996;
\endverbatim
limitMag limits the magnitude of a specified field of any rank to a specified
maximum value. To limit the velocity field U using limitMag rather than
limitVelocity specify
limitU
{
type limitMag;
selectionMode all;
field U;
max 100;
}
in the system/fvConstraints dictionary.
The lookup been fixed to prevent failures when a field is looked up with
the wrong type, and it now also provides warnings when a field cannot be
found for any type.
The unreliable extrapolateProfile option has been replaced by the more flexible
and reliable profile option which allows the velocity profile to be specified as
a Function1 of the normalised distance to the wall. To simplify the
specification of the most common velocity profiles the new laminarBL (quadratic
profile) and turbulentBL (1/7th power law) Function1s are provided.
In addition to the new profile option the flow rate can now be specified as a
meanVelocity, volumetricFlowRate or massFlowRate, all of which are Function1s of
time.
The following tutorials have been updated to use the laminarBL profile:
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesis
multiphase/multiphaseEulerFoam/laminar/titaniaSynthesisSurface
The following tutorials have been updated to use the turbulentBL profile:
combustion/reactingFoam/Lagrangian/verticalChannel
combustion/reactingFoam/Lagrangian/verticalChannelLTS
combustion/reactingFoam/Lagrangian/verticalChannelSteady
compressible/rhoPimpleFoam/RAS/angledDuct
compressible/rhoPimpleFoam/RAS/angledDuctLTS
compressible/rhoPimpleFoam/RAS/squareBendLiq
compressible/rhoPorousSimpleFoam/angledDuctImplicit
compressible/rhoSimpleFoam/angledDuctExplicitFixedCoeff
compressible/rhoSimpleFoam/squareBend
compressible/rhoSimpleFoam/squareBendLiq
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
heatTransfer/chtMultiRegionFoam/shellAndTubeHeatExchanger
incompressible/porousSimpleFoam/angledDuctImplicit
incompressible/porousSimpleFoam/straightDuctImplicit
multiphase/interFoam/RAS/angledDuct
Class
Foam::flowRateInletVelocityFvPatchVectorField
Description
Velocity inlet boundary condition creating a velocity field with
optionally specified profile normal to the patch adjusted to match the
specified mass flow rate, volumetric flow rate or mean velocity.
For a mass-based flux:
- the flow rate should be provided in kg/s
- if \c rho is "none" the flow rate is in m3/s
- otherwise \c rho should correspond to the name of the density field
- if the density field cannot be found in the database, the user must
specify the inlet density using the \c rhoInlet entry
For a volumetric-based flux:
- the flow rate is in m3/s
Usage
\table
Property | Description | Required | Default value
massFlowRate | Mass flow rate [kg/s] | no |
volumetricFlowRate | Volumetric flow rate [m^3/s]| no |
meanVelocity | Mean velocity [m/s]| no |
profile | Velocity profile | no |
rho | Density field name | no | rho
rhoInlet | Inlet density | no |
alpha | Volume fraction field name | no |
\endtable
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
volumetricFlowRate 0.2;
profile laminarBL;
}
\endverbatim
Example of the boundary condition specification for a mass flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
massFlowRate 0.2;
profile turbulentBL;
rho rho;
rhoInlet 1.0;
}
\endverbatim
Example of the boundary condition specification for a volumetric flow rate:
\verbatim
<patchName>
{
type flowRateInletVelocity;
meanVelocity 5;
profile turbulentBL;
}
\endverbatim
The \c volumetricFlowRate, \c massFlowRate or \c meanVelocity entries are
\c Function1 of time, see Foam::Function1s.
The \c profile entry is a \c Function1 of the normalised distance to the
wall. Any suitable Foam::Function1s can be used including
Foam::Function1s::codedFunction1 but Foam::Function1s::laminarBL and
Foam::Function1s::turbulentBL have been created specifically for this
purpose and are likely to be appropriate for most cases.
Note
- \c rhoInlet is required for the case of a mass flow rate, where the
density field is not available at start-up
- The value is positive into the domain (as an inlet)
- May not work correctly for transonic inlets
- Strange behaviour with potentialFoam since the U equation is not solved
See also
Foam::fixedValueFvPatchField
Foam::Function1s::laminarBL
Foam::Function1s::turbulentBL
Foam::Function1s
Foam::flowRateOutletVelocityFvPatchVectorField
With the changes to chemistryModel to evaluate and integrate reaction rates
mass-fraction based rather than mole-fraction based ISAT is now independent of
the thermodynamics and with some restructuring of chemistryModel and the
addition of the non-templated base-class odeChemistryModel is has been possible
to un-template chemistryTabulationMethods and ISAT in particular. This
simplifies the ISAT code and hence maintenance as well as reducing the
compilation time of chemistryModel on the various thermo packages.
This model will generate an error if the diameter is requested. This
will happen if another sub model is included that depends on the
diameter of the continuous phase. It therefore provides a check that the
sub-modelling combination is valid.
Patch contributed by Institute of Fluid Dynamics,
Helmholtz-Zentrum Dresden - Rossendorf (HZDR)
