I have trouble seeing why this can possibly physically justified
(because oil is once the wetting and once the non-wetting phase), but
things seem to be like this as the documentation says that in case of
chosing the relperm hysteresis model 0 via the EHYSTR keyword,
hysteresis is only used for the non-wetting phase.
for grids with many inactive cells, this can change quite a bit of
memory and might even lead to slightly better performance because of
the memory prefetching potentially works better.
it is called "simple" because the usage is somewhat simpler: The
quantities are stored and those which are not can be specified using
simple boolean template arguments instead of having to pass the class
names of the storage modules. The definition of the class is quite a
bit more involved than the non-"simple" variant, though.
Dune's MPIHelper API might be sub-optimal (because it easily leads to
race conditions w.r.t. the destruction of singletons), but it does the
job and we don't have to maintain it.
in some cases this pressure can be quite low (e.g. 0), and für
slightly inconsistent decks it can be even negative, so it makes sense
to compare the absolute values and to add an absolute convergence
criterion.
in fact they wouldn't have needed any modification, but returning
constant references instead of copies of the stored values saves quite
a few calls to copy constructors.
besides this, fluid states are now required to export the 'Scalar'
type, which allows to use it outside of the FluidState without
resorting to the c++ 'decltype' construct.
these are "traits" classes and provide a way to access the value of
function evaluations, conditional access to its value (i.e., to
forward them if the target object of an assignment includes the
derivatives or use the function value if not) and some algebraic
functions.
the main idea is to be able to abstract the differences between plain
scalars and function evaluation...
The basic idea is to replace "plain" scalar values by "function
evaluations": these store the function's value plus a set of
derivatives for it and the chain rule is used to "drag" the
derivatives along.
So far, the framework only implements the "forward" approach to
automatic differentiation and expression templates are not supported
yet. (The latter point may change in the furture, though.)
"local" means that the framework uses static arrays to represent the
derivatives, i.e. the number of derivatives which are required must be
specified at compile time. Compared to dynamic arrays this improves
efficiency considerably if function evaluation objects must be
allocated and deallocated frequently.
they used to be in opm-core, but this allows to be more flexible with
the dependency order: What's now called "opm-core" can easily depend
on opm-material which might come in handy for the refactoring.
Besides moving in classes from opm-core, the infrastructural code
which was still in opm-material is moved to the directory
opm/material/common. The intention is to collect these classes at a
central location to make it easy to move them to a real "core" module.
(if this is ever going to happen.)
i.e., there is no distinction between the "API version" and the
"Release version" anymore. IMO, the split scheme is just confusing for
no benefit because we are handling API/ABI changes in a pretty relaxed
manner anyway: i.e., whenever the "release version" gets incremented,
the "API version" needs to follow suite!
