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...
now the values for X and Y can be added in ascending or descending
order. The descending code path is pretty slow though, and it is still
possible to screw up the object by specifying the inputs in a totally
unsorted manner. (At this place, I don't really care about these two
things, though.)
... instead of just assuming some arbitrary behavior. this fixes SPE9
for eWoms as far as the fluid system is concerned. (the ecl_blackoil
still seems to have some problems with anisotropic permeability. this
will hopefulls be fixed soon.)
currently, this can't happen because opm-material depends mandatorily
on opm-core which in turn requires opm-parser. In the future, this
might change, though...
because it seems like what eclipse uses in the DENSITY keyword is not
really for surface pressure but at the pressure where the phase's
formation volume factor is one. (this pressure does not seem to be
specified and can potentially be different for every fluid phase.)
Thus rename surfaceDensity() to referenceDensity() and remove the
logic to allow volume formation factors which are not equal to one at
the reference pressure. (i.e., formerly the surface pressure.)
it used to be the range of the sampling points. If for some reason the
sampling points describe a subset of the full range, the material laws
use extrapolation outside of the table and properly limit the values
of that operation.
In the real world, the effect of this change is rather limited because
all tested tables used the range...
TODO: adapt the evalDerivative() methods. This is not very urgent, though
because they are usually not used...
compared to the variant which uses linear interpolation, this makes
the resulting curves smoother and thus hopefully improves the
convergence rates of the simulations.
this compiler is for some reason not able to determine the number of
phases for externally defined attributes the way it was done. this is
most likely a compiler bug (or it is a left-over ideosyncrasy from
c++-2003 which was not yet removed for GCC 4.4...)
it is slightly hacky that the ParameterCache is used to specify the
PVT region. Having said that, the multiple PVT regions stuff in no way
based on physical assumptions, but is just a way to fit the black-oil
model to the measured values of real reservoirs...
