OPM/opm-material#310 introduced a few minor coding style
inconsistencies. this patch fixes them; none of its changes are
supposed to alter anything functionality-wise.
this has mildly annoyed me for quite some time, and finally managed to
bring myself to changing it: The Opm::FluidSystems namespace is pretty
useless because the number of classes contained within it is quite
small and mismatch between the naming convention of the file names the
actual classes is somewhat confusing IMO. Thus, this patch changes the
naming of fluid systems from `Opm::FluidSystems::Foo` to
`Opm::FooFluidSystem`.
(also, flat hierarchies currently seem to be popular with the cool
people!?)
this patch requires some simple mop-ups for `ewoms` and `opm-simulators`.
for some reason, the version of 311c1a6 that was merged did still use
the compressed cell index as the logically Cartesian one. I blame it
on the constant back-and-forth debugging when making that patch.
this creates an uninitialized "compatible" evaluation that is
compatible with its argument. For primitive floating point types and
statically-sized Evaluations, this is identical to calling the default
constructor, for dynamically sized ones, it creates an uninitialized
Evaluation object of identical size as the argument.
thanks to [at]GitPaen for the heads up.
this works by passing -1 as the template argument for the number of
derivatives. most of the code is identical, but creation of such
objects requires the number of derivatives passed to the constructor
or the copy constructor must be used.
Finally `DynamicEvaluation<Scalar>` is provided as a more expressive
alias for `Evaluation<Scalar, -1>`.
this means Carlson's hysteresis model for the relperm of the
non-wetting phase and the imbibition instead of the drainage curve for
the relperm of the wetting phase.
so far, compressed element indices have been used to access data for
logical cartesian cells. this does not matter if there is only a
single saturation region for imbibition and thus IMBNUM is
uniform. (e.g., this is the case for Norne as far as I can see.)
this used to be the unmodified quadratic function that results from
integrating a linear function. using the midpoint rule is quite a bit
simpler and should yield the same results.
thanks to [at]atgeirr for pointing this out.
Dune::set_singularity_limit() has been removed there and std::real()
gets used by the dense matrix-vector code (this causes trouble if
`quad` is selected as scalar type)
