most of these people like to inflict pain on themselfs (i.e., warnings
in their own code), but they usually don't like if pain is inflicted
on them by others (i.e., warnings produced by external code which they
use). This patch should make these kinds of people happy. I'm not
really sure if the code is easier to understand with this, but at
least clang does not complain for most of the warnings of
"-Weverything" anymore.
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.)
- the StaticTabulated2DFunction class and the base class
(Tabulated2DFunction) are gone
- the DynamicTabulated2DFunction class has been renamed to
UniformTabulated2DFunction
- a new class called UniformXTabulated2DFunction has been
introduced. Like UniformTabulated2DFunction, it assumes uniform
intervalls of the sampling points in X direction, but in contrast to
UniformTabulated2DFunction, the Y locations of the sampling points
can be set freely (as long as they are specified in increasing order
for each x value)
- add a unit test for the two tabulation classes
Enabled access to these methods in the co2-brine-fluidsystem (only
pure-phase heat capacities are used). reviewed by Klaus
Dumux-Svn-Revison: 12462
Ported-By: Andreas Lauser <and@poware.org>
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.
this lead to a compiler warning on gcc 4.8 that this case was already
covered by catching std::exception. Since we did the same in both
branches anyway, these statements were not required...
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.
