For some cases, in particular those with very small cells created by snapping in
corners for example, it may be beneficial to convergence rate to limit the
minimum LTS time-step, the new minDeltaT control provides this.
This permits forward declaration of the boundary and internal fields.
References and pointers to boundary fields and sliced internal fields
can now be used in situations where full instantiation of the geometric
field is not possible due to cyclic dependencies.
It has been possible as a result of this change to type the pointer to
the cell volumes field in fvMesh. Previously this was done with a void
pointer and explicit casting.
to limit the time-step by comparing the film Courant number with the maximum
Courant number obtain from the optional maxCo entry in the system/<film
region>/fvSolution file. If maxCo is not provided the film model does not limit
the time-step.
See tutorials/multiphase/compressibleInterFoam/laminar/cylinder as an example
demonstrating this functionality.
when evaluating the external total pressure from the static pressure and
tangential velocity. This improves numerical stability and solution smoothness
for compressible cases.
The external pressure p0 is now formally the static pressure in the presence of
tangential flow and the corresponding total pressure is calculated from this
static pressure using the tangential velocity obtained from the
pressureInletOutletVelocity boundary condition if available. In the case that
there is no external tangential flow the external total pressure is equal to the
static pressure p0 as before.
Description
Inflow, outflow and entrainment pressure boundary condition based on a
constant total pressure assumption.
For outflow the patch pressure is set to the external static pressure.
For inflow the patch pressure is evaluated from the patch velocity and the
external total pressure obtained from the external static pressure \c p_0
and external velocity \c U_0 which is looked-up from the the optional \c
tangentialVelocity entry in the \c pressureInletOutletVelocity velocity
boundary condition for the patch if that boundary condition is used,
otherwise \c U_0 is assumed zero and the external total pressure is equal to
the external static pressure.
The patch pressure is evaluated from the external conditions using one of
the following expressions depending on the flow conditions and
specification of compressibility:
1. incompressible subsonic:
\f[
p_p = p_0 + 0.5 |U_0|^2 - 0.5 |U|^2
\f]
where
\vartable
p_p | pressure at patch [m^2/s^2]
p_0 | external static pressure [m^2/s^2]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
2. compressible subsonic:
\f[
p_p = p_0 + 0.5 \rho |U_0|^2 - 0.5 \rho |U|^2
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\rho | density [kg/m^3]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
3. compressible transonic (\f$\gamma = 1\f$):
\f[
p_p = \frac{p_0 + 0.5 \rho |U_0|^2}{1 + 0.5 \psi |U|^2}
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\psi | compressibility [m^2/s^2]
\rho | density [kg/m^3]
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
4. compressible supersonic (\f$\gamma > 1\f$):
\f[
p_p = \frac{p_0 + 0.5 \rho |U_0|^2}
{(1 + 0.5 \psi G |U|^2)^{\frac{1}{G}}}
\f]
where
\vartable
p_p | pressure at patch [Pa]
p_0 | external static pressure [Pa]
\psi | compressibility [m^2/s^2]
\rho | density [kg/m^3]
G | coefficient given by \f$\frac{\gamma}{1-\gamma}\f$ []
\gamma | ratio of specific heats (Cp/Cv) []
U | velocity [m/s]
U_0 | external velocity [m/s]
\endvartable
The modes of operation are set by the dimensions of the pressure field
to which this boundary condition is applied, the \c psi entry and the value
of \c gamma:
\table
Mode | dimensions | psi | gamma
incompressible subsonic | p/rho | |
compressible subsonic | p | none |
compressible transonic | p | psi | 1
compressible supersonic | p | psi | > 1
\endtable
Usage
\table
Property | Description | Required | Default value
U | Velocity field name | no | U
phi | Flux field name | no | phi
rho | Density field name | no | rho
psi | Compressibility field name | no | none
gamma | (Cp/Cv) | no | 1
p0 | External pressure | yes |
\endtable
Example of the boundary condition specification:
\verbatim
<patchName>
{
type totalPressure;
p0 uniform 1e5;
}
\endverbatim
For most multiphase flows it is more appropriate to evaluate the total pressure
from the static pressure obtained from p_rgh rather than from p_rgh directly.
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))
