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;
}
If divU is valid the velocity divergence is included in the pcorr equation.
This simplifies the logic in multiphase moveMesh functions supporting
incompressible (with or without mass sources) and compressible fluids.
The cell-base momentum/pressure algorithm in the multiphaseEuler solver module
has been substantially updated to improve consistency, conservation and reduce
drag generated staggering patterns at sharp interfaces and the boundaries with
stationary phases. For most if not all cases this new algorithm can be used to
provide well resolved and reliable solutions where the faceMomentum algorithm
would have been chosen previously in order to obtain sufficiently smooth
solutions but at the expense of a noticeable loss in accuracy and resolution.
The first significant change in the momentum/pressure algorithm is in the
interpolation practice used to construct the flux predictor equation from the
cell momentum equation: rather than interpolating the H/A ratio to the faces
i.e. (H/A)_f the terms in the momentum equation are interpolated separately so
that H_f/A_f is used. The same approach is used for the drag i.e. (D_f/A_f) and
virtual mass contributions. The advantage of this change is that the phase
forces are now consistent in both the momentum and flux equations, i.e. sum to
zero for each pair of phases.
The second significant change is in the handling of ddtCorr which converts the
old-time time-derivative contributions in H from velocity to flux which is now
consistent due to the change to H/A interpolation and also generalised to use
the fvc::ddtCorr function which has been updated for multiphase. Additionally
ddtCorr may optionally be applied to the time-derivative in the virtual mass
term in a consistent manner so that the contributions to the flux equation sum
to zero for each pair of phases.
The third significant change is the addition of an optional drag correction term
to the momentum corrector to reduce the staggering patters generated in the
velocity field due to sudden changes in drag force between phase, e.g. at sharp
interfaces between phases or at the boundaries with stationary phases. This is
particularly beneficial for fluidised bed simulations. However this correction
is not and cannot be phase consistent, i.e. the correction does not sum to zero
for pairs of phases it is applied to so a small drag error is introduced, but
tests so far have shown that the error is small and outweighed by the benefit in
the reduction in numerical artefacts in the solution.
The final significant change is in the handling of residualAlpha for drag and
virtual mass to provide stable and physical phase velocities in the limit of the
phase-fraction -> 0. The new approach is phase asymmetric such that the
residual drag is applied only to the phase with a phase-fraction less than
residualAlpha and not to the carrier phase. This change ensures that the flow
of a pure phase is unaffected by the residualAlpha and residual drag of the
other phases that are stabilised in pure phase region.
There are now four options in the PIMPLE section of the fvSolutions dictionary
relating to the multiphase momentum/pressure algorithm:
PIMPLE
{
faceMomentum no;
VmDdtCorrection yes;
dragCorrection yes;
partialElimination no;
}
faceMomentum:
Switches between the cell and face momentum equation algorithms.
Provides much smoother and reliable solutions for even the most challenging
multiphase cases at the expense of a noticeable loss in accuracy and resolution.
Defaults to 'no'.
VmDdtCorrection:
Includes the ddtCorr correction term to the time-derivative part of the
virtual-mass term in the flux equation which ensures consistency between the
phase virtual mass force on the faces but generates solutions which are
slightly less smooth and more likely to contain numerical artefacts.
Defaults to 'no'.
Testing so far has shown that the loss in smoothness is small and there is
some noticeable improvement is some cases so in the future the default may
be changed to 'yes'.
dragCorrection:
Includes the momentum corrector drag correction term to reduce the
staggering patters generated in the velocity field due to sudden changes in
drag force at the expense of a small error in drag consistency.
Defaults to 'no'
partialElimination:
Switches the partial-elimination momentum corrector which inverts the drag
matrix for both the momentum equations and/or flux equations to provide a
drag implicit correction to the phase velocity and flux fields. The
algorithm is the same as previously but updated for the new consistent drag
interpolation.
All the tutorials/modules/multiphaseEuler tutorial cases have been updated and
tested with the above developments and the four options set appropriately for
each.
The mixture compressibility/density is now included in CorrectPhi for
compressible mixtures, consistent with the compressibility handling in the
pressure equation. This improves consistency, robustness and convergence of the
pcorr equation.
so that the residualAlpha applied to stabilised the dispersed phase does not
affect the continuous phase in the limit of it becoming pure with or without
partial-elimination.
Flux correction is now applied if either the topology changed or the mesh is
moving and correctPhi is true. This strategy allows moving mesh cases without
topology change to be run without any change to the fluxes which is appropriate
for solid-body motion of the entire domain or a rotating sub-domain with NCC.
to provide the old-time absolute flux. This avoids possible
pressure-velocity-flux decoupling (staggering) within the MRF region using
ddtCorr to better couple the velocity and flux fields.
A new wallBoiling heat transfer model has been added for use with the
thermalPhaseChangeMultiphaseSystem. This model operates similarly to the
alphatWallBoilingWallFunction. The difference is that the boiling generated by
the wallBoiling heat transfer model occurs on the surface of a third stationary
phase, within the volume of the simulation, rather than on a wall patch. This
can be used to model boiling within a packed bed or similar.
The wallBoiling heat transfer model and the alphatWallBoilingWallFunction share
underlying sub-models, so their specification is very similar. For example, in
constant/phaseProperties:
heatTransfer
{
...
bed_dispersedIn_liquid_inThe_liquid
{
type wallBoiling;
liquidPhase liquid;
vapourPhase gas;
heatTransferModel
{
type Gunn;
}
partitioningModel
{
type Lavieville; // phaseFraction, linear, cosine
alphaCrit 0.2;
}
nucleationSiteModel
{
type LemmertChawla; // KocamustafaogullariIshii
}
departureDiameterModel
{
type TolubinskiKostanchuk; // KocamustafaogullariIshii
}
departureFrequencyModel
{
type KocamustafaogullariIshii; // Cole
Cf 1.18;
}
}
bed_dispersedIn_liquid_inThe_bed
{
type spherical;
}
...
}
Based on a patch contributed by Juho Peltola, VTT.
used in the alphaContactAngleFvPatchScalarField boundary condition to replace
the need to derive specialised versions for different contact angle evaluation
methods. This simplifies the code and provides a reusable system which could be
applied to other multiphase contact angle boundary conditions.
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.
Latent heat evaluation has been changed to calculate both sides' heats
similarly using the interface temperature, rather than using bulk
quantities on the "upwind" side of the mass transfer process
(latentHeatScheme::symmetric vs latentHeatScheme::upwind).
The transfer of heat has been changed so that it is calculated from the
mass transfer rate rather than the heat transfer coefficients and
temperatures (latentHeatTransfer::mass vs latentHeatTransfer::heat).
These changes were found to improve stability characteristics in some
boiling cases, and in general should be more energy conservative and
less dependent on the accuracy of the interfacial temeprature solution.
Patch contributed by Juho Peltola, VTT.
The patch field 'autoMap' and 'rmap' functions have been replaced with a
single 'map' function that can used to do any form of in-place
patch-to-patch mapping. The exact form of mapping is now controlled
entirely by the mapper object.
An example 'map' function is shown below:
void nutkRoughWallFunctionFvPatchScalarField::map
(
const fvPatchScalarField& ptf,
const fvPatchFieldMapper& mapper
)
{
nutkWallFunctionFvPatchScalarField::map(ptf, mapper);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
mapper(Ks_, nrwfpsf.Ks_);
mapper(Cs_, nrwfpsf.Cs_);
}
This single function replaces these two previous functions:
void nutkRoughWallFunctionFvPatchScalarField::autoMap
(
const fvPatchFieldMapper& m
)
{
nutkWallFunctionFvPatchScalarField::autoMap(m);
m(Ks_, Ks_);
m(Cs_, Cs_);
}
void nutkRoughWallFunctionFvPatchScalarField::rmap
(
const fvPatchScalarField& ptf,
const labelList& addr
)
{
nutkWallFunctionFvPatchScalarField::rmap(ptf, addr);
const nutkRoughWallFunctionFvPatchScalarField& nrwfpsf =
refCast<const nutkRoughWallFunctionFvPatchScalarField>(ptf);
Ks_.rmap(nrwfpsf.Ks_, addr);
Cs_.rmap(nrwfpsf.Cs_, addr);
}
Calls to 'autoMap' should be replaced with calls to 'map' with the same
mapper object and the patch field itself provided as the source. Calls
to 'rmap' should be replaced with calls to 'map' by wrapping the
addressing in a 'reverseFvPatchFieldMapper' (or
'reversePointPatchFieldMapper') object.
This change simplifies the creation of new patch fields and hence
improves extensibility. It also provides more options regarding general
mapping strategies between patches. Previously, general abstracted
mapping was only possible in 'autoMap'; i.e., from a patch to itself.
Now, general mapping is possible between different patches.
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);
}
This change means that even if the Courant number is zero, the time step
is adjusted based on maximum time step settings and/or constraints
specified by active fvModels. If none of these additional constraints
are present then adjustment is deactivated.
This change lets the solver be looked up from the region database, so
that aspects of the solution algorithm can be accessed by
functionObjects and fvModels and similar. For example, a fluid solver
could be looked up as follows:
const solvers::fluid& s =
mesh().lookupObject<solvers::fluid>(solver::typeName);
Wall boiling properties and state have been named consistently through
the wall boiling boundary conditions and all of its related sub-models.
All changes are backwards compatible. Changes to tutorials will follow
in a separate commit.
A small SuSp stabilisation has been added to the dilation error term to
prevent edge-cases in which the dilation correction exactly cancels out
all implicit transport terms and sources.
