MULES and CMULES have been extended so that the limits can be supplied
as fields. These arguments are templated so that zeroField, oneField or
UniformField<scalar> can be used in place of a scalar value with no
additional overhead. The flux argument has been removed from the
unlimited CMULES correct functions in order to make this templating
possible.
An additional form of limit sum has also been added to MULES. This
limits the flux sum by ofsetting in proportion to the phase fraction,
rather than by reducing the magnitude of the fluxes with the same sign
as the imbalance. The new procedure makes it possible to limit the flux
sum in the presence of constraints without encountering a divide by
zero.
Partial elimination has been implemented for the multiphase Euler-Euler
solver. This does a linear solution of the drag system when calculating
flux and velocity corrections after the solution of the pressure
equation. This can improve the behaviour of the solution in the event
that the drag coupling is high. It is controlled by means of a
"partialElimination" switch within the PIMPLE control dictionary in
fvSolution.
A re-organisation has also been done in order to remove the exposure of
the sub-modelling from the top-level solver. Rather than looping the
drag, virtual mass, lift, etc..., models directly, the solver now calls
a set of phase-system methods which group the different force terms.
These new methods are documented in MomentumTransferPhaseSystem.H. Many
other accessors have been removed as a consequence of this grouping.
A bug was also fixed whereby the face-based algorithm was not
transferring the momentum associated with a given interfacial mass
transfer.
Avoids slight phase-fraction unboundedness at entertainment BCs and improved
robustness.
Additionally the phase-fractions in the multi-phase (rather than two-phase)
solvers are adjusted to avoid the slow growth of inconsistency ("drift") caused
by solving for all of the phase-fractions rather than deriving one from the
others.
Previously the inlet flow of phase 1 (the phase solved for) is corrected
to match the inlet specification for that phase. However, if the second
phase is also constrained at inlets the inlet flux must also be
corrected to match the inlet specification.
When the GeometricBoundaryField template class was originally written it
was a separate class in the Foam namespace rather than a sub-class of
GeometricField as it is now. Without loss of clarity and simplifying
code which access the boundary field of GeometricFields it is better
that GeometricBoundaryField be renamed Boundary for consistency with the
new naming convention for the type of the dimensioned internal field:
Internal, see commit a25a449c9e
This is a very simple text substitution change which can be applied to
any code which compiles with the OpenFOAM-dev libraries.
Given that the type of the dimensioned internal field is encapsulated in
the GeometricField class the name need not include "Field"; the type
name is "Internal" so
volScalarField::DimensionedInternalField -> volScalarField::Internal
In addition to the ".dimensionedInternalField()" access function the
simpler "()" de-reference operator is also provided to greatly simplify
FV equation source term expressions which need not evaluate boundary
conditions. To demonstrate this kEpsilon.C has been updated to use
dimensioned internal field expressions in the k and epsilon equation
source terms.
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1938
Because C++ does not support overloading based on the return-type there
is a problem defining both const and non-const member functions which
are resolved based on the const-ness of the object for which they are
called rather than the intent of the programmer declared via the
const-ness of the returned type. The issue for the "boundaryField()"
member function is that the non-const version increments the
event-counter and checks the state of the stored old-time fields in case
the returned value is altered whereas the const version has no
side-effects and simply returns the reference. If the the non-const
function is called within the patch-loop the event-counter may overflow.
To resolve this it in necessary to avoid calling the non-const form of
"boundaryField()" if the results is not altered and cache the reference
outside the patch-loop when mutation of the patch fields is needed.
The most straight forward way of resolving this problem is to name the
const and non-const forms of the member functions differently e.g. the
non-const form could be named:
mutableBoundaryField()
mutBoundaryField()
nonConstBoundaryField()
boundaryFieldRef()
Given that in C++ a reference is non-const unless specified as const:
"T&" vs "const T&" the logical convention would be
boundaryFieldRef()
boundaryFieldConstRef()
and given that the const form which is more commonly used is it could
simply be named "boundaryField()" then the logical convention is
GeometricBoundaryField& boundaryFieldRef();
inline const GeometricBoundaryField& boundaryField() const;
This is also consistent with the new "tmp" class for which non-const
access to the stored object is obtained using the ".ref()" member function.
This new convention for non-const access to the components of
GeometricField will be applied to "dimensionedInternalField()" and "internalField()" in the
future, i.e. "dimensionedInternalFieldRef()" and "internalFieldRef()".
This formulation provides C-grid like pressure-flux staggering on an
unstructured mesh which is hugely beneficial for Euler-Euler multiphase
equations as it allows for all forces to be treated in a consistent
manner on the cell-faces which provides better balance, stability and
accuracy. However, to achieve face-force consistency the momentum
transport terms must be interpolated to the faces reducing accuracy of
this part of the system but this is offset by the increase in accuracy
of the force-balance.
Currently it is not clear if this face-based momentum equation
formulation is preferable for all Euler-Euler simulations so I have
included it on a switch to allow evaluation and comparison with the
previous cell-based formulation. To try the new algorithm simply switch
it on, e.g.:
PIMPLE
{
nOuterCorrectors 3;
nCorrectors 1;
nNonOrthogonalCorrectors 0;
faceMomentum yes;
}
It is proving particularly good for bubbly flows, eliminating the
staggering patterns often seen in the air velocity field with the
previous algorithm, removing other spurious numerical artifacts in the
velocity fields and improving stability and allowing larger time-steps
For particle-gas flows the advantage is noticeable but not nearly as
pronounced as in the bubbly flow cases.
Please test the new algorithm on your cases and provide feedback.
Henry G. Weller
CFD Direct
