with this, I got slightly better performance than the opm-core master
version if flow is tasked on simulating the full Norne deck. Be aware
that from the physical POV, this is wrong.
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.
