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!
This reverts commit 1cf745943a. After a
more thorough investigation, the cannonical name of these quantities
turned out to be "* formation volume factor"...
This is only relevant for the approximation which uses large instead
of infinite fugacity coefficients for immiscible components. The
motivation is to bring the solution of the NCP flash solver closer to
what's expected using the blackoil assumptions directly. (Physically
speaking, the result is less realistic in most cases, though...)
i.e., interpolate between inverse volume factors and the inverse of
the product of the volume factors. I have my doubts if these
"optimizations" make the results physically better, but it seems like
they at least make things different...
these were unused, quite likely broken and could only calculate the
derivatives with regard to some quantities.
if the general derivatives of the relperms and capillary pressures are
ever required, finite differences can be used to save the
day... (these *might* be sightly slower, but they are automatically
consistent with the function.)
at least it seems to be very similar for SPE1. the difference in the
BHP of the wells for SPE1 is significantly reduced (but still too
large) by this...
this is much closer to how things are done in Eclipse. For the
external API, nothing changes provided that only the "official" fluid
system API is used...
