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)
after #278, the generic version of getInvB_() was always used because
no argument for fluidState.invB() was specified when invoking the
GENERATE_HAS_MEMBER() macro, so has_invB<FluidState>() returned false
for any fluid state. since the getInvB_() function is not used by the
master version of `flow` yet, it was unaffected by this issue and this
is also the reason why neither Jenkins complained nor any performance
regression could be seen after #278. That said, for implementing
non-trivial boundary conditions, it is very helpful to have a unified
code path for the case where boundary conditions are specified using
generic fluid states and black-oil model specific ones as well as with
the flux computations in the interior of the domain.
Note that I only found this issue due to the fact that on my current
WIP branch linearization got 10% slower for Norne. This means that the
generic version of this function must be correct and, considering the
fact that the massFraction() method is quite elaborate for
BlackOilFluidState, this is also a very strong indication that on
modern processors the performance of even the linearization part of
the simulation is more limited by memory latency than by the execution
speed of the ALUs.
