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)
used in conjunction with the new loadBalancing option in constant/chemistryProperties:
loadBalancing on;
which enables per-cell CPU time caching used by the loadBalancer to redistribute
the mesh. Currently this option is only provided for chemistry integration but
the implementation is general and in future options will be provided to balance
other local cell loads, in particular Lagrangian particles.
The loadBalancer in enabled by specifying a distributor entry in
constant/dynamicMeshDict, e.g.
distributor
{
type loadBalancer;
libs ("libfvMeshDistributors.so");
multiConstraint true;
// How often to redistribute
redistributionInterval 10;
// Maximum fractional cell distribution imbalance
// before rebalancing
maxImbalance 0.1;
}
with which the mesh is checked for more than 10% load-imbalance every 10
time-steps and redistributed using a multi-constraint method, i.e. separate CPU
load weights are provided for each of the loads, currently that is the chemistry
integration load and the CPU time taken for the rest of the simulation,
transport equations solution etc.
The fvMeshDistributors::loadBalancer uses the distributor specified in
system/decomposeParDict to redistribute the mesh based on the cell CPU loads,
e.g. to use the Zoltan RCB method specify:
distributor zoltan;
libs ("libzoltanDecomp.so");
zoltanCoeffs
{
lb_method rcb;
}
Unfortunately only a few available redistribution methods support
multi-constraints: Zoltan::RCB, MeTiS, parMeTiS and xtraPuLP, of these only
Zoltan::RCB is currently available in OpenFOAM. Load-balancing is possible
without using a multi-constraint method (i.e. using any of the other
decomposition methods provided with OpenFOAM and Zoltan) by summing the various
CPU loads which is selected by setting:
multiConstraint false;
but the load-balancing is likely to be a lot less effective with this option.
Due to the licencing issues with parMeTiS interfacing to xtraPuLP might be the
best option for further work on load-balancing in OpenFOAM, or MeTiS could be
used in parallel by first agglomerating the distribution graph on the master
processor and redistributing the result; this pseudo-parallel option is already
provided for the Scotch method.
This utility initialises the U, k and epsilon fields (if available) to
the output of the atmBoundaryLayer model. This is the same model as used
in the atmBoundaryLayerInlet.* boundary conditions and in the
waveAtmBoundaryLayer wave model.
The settings for the initialisation are read from a
system/setAtmBoundaryLayerDict file and are identical to the settings
required by the other use cases. An example of the settings required
within a system/setAtmBoundaryLayerDict file is shown below:
zDir (0 0 1); // Vertical direction
flowDir (1 0 0); // Direction of far-field flow
Zref 20; // Reference height
Uref 10; // Speed at reference height
z0 uniform 0.1; // Roughness height
zGround uniform 0; // Ground height
which provides better resolution of the CPU time than times function used
previously. This will be needed for load-balancing chemistry, Lagrangian
etc. for which the CPU time spent per cell is required.
Now that Cp and Cv are cached it is more convenient and consistent and slightly
more efficient to cache thermal conductivity kappa rather than thermal
diffusivity alpha which is not a fundamental property, the appropriate form
depending on the energy solved for. kappa is converted into the appropriate
thermal diffusivity for the energy form solved for by dividing by the
corresponding cached heat capacity when required, which is efficient.
