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.)
because these classes should not have any side effects. case in point:
the warnings intended to be printed once get printed once per process
which can be quite a few times for parallel simulations with thousands
of cores. This could also be avoided by checking the MPI rank, but
IMHO this is way too much boilerplate code for a feature of questionable
value.
basically the only Dune thing which is still used are the FieldVector
and FieldMatrix classes used by some constraint solvers. Until
something similar goes into opm-core, opm-material must depend on
dune-common...
use 'const' instead to make old compilers happy. the disadvantage is
that you cannot use the normal methods for template specialization,
but this currently should not be a major drawback.
