this hopefully makes the purpose of `ebos` clear in its
description. this prose should be interpreted as "if you use ebos in
production, you are on your own and you should only expect a very
limited amount of support (or even sympathy) if something breaks".
in particular the missing synchronization after restarts was very
nasty to find. thanks a ton for pointing this out!
also, IIRC changing DR[SV]DT in the schedule section has been working
properly for a while, so the comment which stated the opposite is
removed as well.
Some time loop stuff was missing in the doobly-doo, the init() method
of the well model was not called and there was the slightly deeper
issue that the initial solutions where not calculated on restarts
which breaks everything that relies on them. (at the moment, that's
everything which is related to non-trivial boundary contitions.)
the purpose of this was a hack to be able to manipulate the Jacobian
matrix directly from outside code. Since `flow` has been converted to
the eWoms wells API, this is not required anymore.
This seems to be covered for types and functions by our coding style
with room for interpretation. For variables the coding styles asks for
underlines though, but nevermind.
The former order resulted of first apply NCC to the grid
transmissibilities and then applying EDITNNC resulted in NNCs being
scaled twices. The reason is that applyNNCToGridTrans_ scales the NNC
with EDITNNC. With the patch the order of the function calls is
reversed to prevent double scaling.
This is includes neighboring connection and NNCs due to faults. In both
cases the transmissibilities of specified via NNC are added to the set or
computed ones.
This is the first step for supporting NNC in flow.
the parameter is called `EclNewtonSumToleranceExponent`. if it is set
to 1, the specified tolerance will be used directly. (this is not
desireable in the general case though, because at the same result
quality, the sum error for large reservoirs can be larger than for
small ones.)
albeit, we scale the error only to the cube root of the pore
volume. the rationale is that the same amount of mass can get lost
"along" a line for each timestep.
maybe it would be a good idea to do something like this for time step
size as well because taking multiple small time steps currently allows
a much larger error in the result than doing it in one big step.
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]
```
