this is done by introducing an "IndexTraits" template parameter to the
BlackOilFluidSystem class which only specifies
`{oil,gas,water}{Phase,Comp}Idx`. By default, nothing which faces user
code changes.
the flags which I used are
```
-pedantic \
-Wall \
-Wextra \
-Wformat-nonliteral \
-Wcast-align
-Wpointer-arith \
-Wmissing-declarations \
-Wcast-qual \
-Wshadow
-Wwrite-strings \
-Wchar-subscripts \
-Wredundant-decls \
-fstrict-overflow \
-O3 \
-march=native \
-DNDEBUG=1
```
note that some heavy filtering is not the worst idea because DUNE is
far from not emiting any warnings with these flags.
also, if quadruple precision math is enabled, GCC complains that a
non-standard floating point signifier suffix is used in quad.hpp. As
far as I can see there's nothing that can be done about that.
... because every 2D function depends on two variables which are
usually called X and Y. The name of that class is still clunky,
suggestions are appreciated.
(also, UniformXTabulated2DFunction is a bad name. I also take
suggestions for that.)
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>`.
