"pos" now returns 1 if the argument is greater than 0, otherwise it returns 0.
This is consistent with the common mathematical definition of the "pos" function:
https://en.wikipedia.org/wiki/Sign_(mathematics)
However the previous implementation in which 1 was also returned for a 0
argument is useful in many situations so the "pos0" has been added which returns
1 if the argument is greater or equal to 0. Additionally the "neg0" has been
added which returns 1 if if the argument is less than or equal to 0.
Now the interFoam and compressibleInterFoam families of solvers use the same
alphaEqn formulation and supporting all of the MULES options without
code-duplication.
The semi-implicit MULES support allows running with significantly larger
time-steps but this does reduce the interface sharpness.
The previous time-step compression flux is not valid/accurate on the new mesh
and it is better to re-calculate it rather than map it from the previous mesh to
the new mesh.
Required to support LTS with the -postProcess option with sub-models dependent on ddt
terms during construction, in particular reactingTwoPhaseEulerFoam.
These new names are more consistent and logical because:
primitiveField():
primitiveFieldRef():
Provides low-level access to the Field<Type> (primitive field)
without dimension or mesh-consistency checking. This should only be
used in the low-level functions where dimensional consistency is
ensured by careful programming and computational efficiency is
paramount.
internalField():
internalFieldRef():
Provides access to the DimensionedField<Type, GeoMesh> of values on
the internal mesh-type for which the GeometricField is defined and
supports dimension and checking and mesh-consistency checking.
In order to simplify expressions involving dimensioned internal field it
is preferable to use a simpler access convention. Given that
GeometricField is derived from DimensionedField it is simply a matter of
de-referencing this underlying type unlike the boundary field which is
peripheral information. For consistency with the new convention in
"tmp" "dimensionedInteralFieldRef()" has been renamed "ref()".
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.
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()".
e.g. (fvc::interpolate(HbyA) & mesh.Sf()) -> fvc::flux(HbyA)
This removes the need to create an intermediate face-vector field when
computing fluxes which is more efficient, reduces the peak storage and
improved cache coherency in addition to providing a simpler and cleaner
API.
The deprecated non-const tmp functionality is now on the compiler switch
NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC
in the Make/options file. However, it is recommended to upgrade all
code to the new safer tmp by using the '.ref()' member function rather
than the non-const '()' dereference operator when non-const access to
the temporary object is required.
Please report any problems on Mantis.
Henry G. Weller
CFD Direct.
The boundary conditions of HbyA are now constrained by the new "constrainHbyA"
function which applies the velocity boundary values for patches for which the
velocity cannot be modified by assignment and pressure extrapolation is
not specified via the new
"fixedFluxExtrapolatedPressureFvPatchScalarField".
The new function "constrainPressure" sets the pressure gradient
appropriately for "fixedFluxPressureFvPatchScalarField" and
"fixedFluxExtrapolatedPressureFvPatchScalarField" boundary conditions to
ensure the evaluated flux corresponds to the known velocity values at
the boundary.
The "fixedFluxPressureFvPatchScalarField" boundary condition operates
exactly as before, ensuring the correct flux at fixed-flux boundaries by
compensating for the body forces (gravity in particular) with the
pressure gradient.
The new "fixedFluxExtrapolatedPressureFvPatchScalarField" boundary
condition may be used for cases with or without body-forces to set the
pressure gradient to compensate not only for the body-force but also the
extrapolated "HbyA" which provides a second-order boundary condition for
pressure. This is useful for a range a problems including impinging
flow, extrapolated inlet conditions with body-forces or for highly
viscous flows, pressure-induced separation etc. To test this boundary
condition at walls in the motorBike tutorial case set
lowerWall
{
type fixedFluxExtrapolatedPressure;
}
motorBikeGroup
{
type fixedFluxExtrapolatedPressure;
}
Currently the new extrapolated pressure boundary condition is supported
for all incompressible and sub-sonic compressible solvers except those
providing implicit and tensorial porosity support. The approach will be
extended to cover these solvers and options in the future.
Note: the extrapolated pressure boundary condition is experimental and
requires further testing to assess the range of applicability,
stability, accuracy etc.
Henry G. Weller
CFD Direct Ltd.
fvOptions are transferred to the database on construction using
fv::options::New which returns a reference. The same function can be
use for construction and lookup so that fvOptions are now entirely
demand-driven.
The abstract base-classes for fvOptions now reside in the finiteVolume
library simplifying compilation and linkage. The concrete
implementations of fvOptions are still in the single monolithic
fvOptions library but in the future this will be separated into smaller
libraries based on application area which may be linked at run-time in
the same manner as functionObjects.
so that the specification of the name and dimensions are optional in property dictionaries.
Update tutorials so that the name of the dimensionedScalar property is
no longer duplicated but optional dimensions are still provided and are
checked on read.
LTS is selected by the ddt scheme e.g. in the
tutorials/multiphase/interFoam/ras/DTCHull case:
ddtSchemes
{
default localEuler rDeltaT;
}
LTSInterFoam is no longer needed now that interFoam includes LTS
support.
fvOptions does not have the appropriate structure to support MRF as it
is based on option selection by user-specified fields whereas MRF MUST
be applied to all velocity fields in the particular solver. A
consequence of the particular design choices in fvOptions made it
difficult to support MRF for multiphase and it is easier to support
frame-related and field related options separately.
Currently the MRF functionality provided supports only rotations but
the structure will be generalized to support other frame motions
including linear acceleration, SRF rotation and 6DoF which will be
run-time selectable.
nLimiterIter: Number of iterations during limiter construction
3 (default) is sufficient for 3D simulations with a Courant number 0.5 or so
For larger Courant numbers larger values may be needed but this is
only relevant for IMULES and CMULES
smoothLimiter: Coefficient to smooth the limiter to avoid "diamond"
staggering patters seen in regions of low particle phase-fraction in
fluidised-bed simulations.
The default is 0 as it is not needed for all simulations.
A value of 0.1 is appropriate for fluidised-bed simulations.
The useful range is 0 -> 0.5.
Values larger than 0.5 may cause excessive smearing of the solution.
Allows the specification of a reference height, for example the height
of the free-surface in a VoF simulation, which reduces the range of p_rgh.
hRef is a uniformDimensionedScalarField specified via the constant/hRef
file, equivalent to the way in which g is specified, so that it can be
looked-up from the database. For example see the constant/hRef file in
the DTCHull LTSInterFoam and interDyMFoam cases.
This is an experimental feature demonstrating the potential of MULES to
create bounded solution which are 2nd-order in time AND space.
Crank-Nicolson may be selected on U and/or alpha but will only be fully
2nd-order if used on both within the PIMPLE-loop to converge the
interaction between the flux and phase-fraction. Note also that
Crank-Nicolson may not be used with sub-cycling but all the features of
semi-implicit MULES are available in particular MULESCorr and
alphaApplyPrevCorr.
Examples of ddt specification:
ddtSchemes
{
default Euler;
}
ddtSchemes
{
default CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) CrankNicolson 0.9;
ddt(rho,U) CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) Euler;
ddt(rho,U) CrankNicolson 0.9;
}
ddtSchemes
{
default none;
ddt(alpha) CrankNicolson 0.9;
ddt(rho,U) Euler;
}
In these examples a small amount of off-centering in used to stabilize
the Crank-Nicolson scheme. Also the specification for alpha1 is via the
generic phase-fraction name to ensure in multiphase solvers (when
Crank-Nicolson support is added) the scheme is identical for all phase
fractions.
