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.)
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.)
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.