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, there were some pesky warnings in test_ecl_output which I don't
know how to fix:
```
tests/test_ecl_output.cc:218:73: warning: missing initializer for member ‘Opm::data::Connection::effective_Kh’ [-Wmissing-field-initializers]
```
this allows the key names to be transformed, i.e.,
```
enable-vtk=true
```
is now also possible in parameter files whereas before only CamelCase
parameter names like
```
EnableVtk=true
```
were valid. besides this, any valid Windows INI file that does not use
parameter groups should be readable, i.e., semicolons are now also
treated as a comment indicator.
this is only relevant people who are masochistic enough to go beyond
`-Wall`. (note that at this warning level, there is plenty of noise from
Dune and other upstream dependencies.)
further, this cleans up the code of the parameter system and the
startup routines a bit and finally, it adds positional parameters
support to ebos as well as brief descriptions to ebos and the lens
problem.
Use a mutex to ensures that only a single prints at the same
time. this should prevent garbled terminal output and thus makes the
it much easier to read. on the flipside, some race conditions may go
unnoticed.
this leads to crashes deeply inside libecl. My cursory hypotheses are
that this test makes the assumption that the output is written
synchronously (it tries to read back the results from disk
immediately) and/or that libecl is not threadsafe.
Dune::set_singularity_limit() was removed and the ILU preconditioners
seem to have been refactored. The ILU refactoring included making the
order of the preconditioner a template parameter of the preconditioner
class, i.e., it can no longer be specified at runtime.
Note that the AMG code in the dune master currently produces quite a
few warnings because of the latter point, but as far as I can see,
there is nothing which can be done about this from outside of
dune-istl.
IMO the term "vanguard" expresses better what these classes are
supposed to do: level the ground for the cavalry. Normally this simply
means to create and distribute a grid object, but it can become quite
a bit more complicated, as exemplified by the vanguard classes of
ebos..
instead of passing a "minimal" fluid state that defines the
thermodynamic conditions on the domain boundary and the models
calculating everything they need based on this, it is now assumed that
all quantities needed by the code that computes the boundary fluxes
are defined. This simplifies the boundary flux computation code, it
allows to get rid of the `paramCache` argument for these methods and
to potentially speed things up because quantities do not get
re-calculated unconditionally.
on the flipside, this requires slightly more effort to define the
conditions at the boundary on the problem level and it makes it less
obvious which quantities are actually used. That said, one now has the
freedom to shoot oneself into the foot more easily when specifying
boundary conditions and also tools like valgrind or ASAN will normally
complain about undefined quantities if this happens.
