* fixed the issue of including ghost cells in preconditioning, by zeroing out ghost rows and setting the diagonal to a large value.
* move altering of matrix to a function
* blockwise modification of matrix
* add findOverlapRowsAndColumns in BlacoilDetail. Add call to findOverlapRowsAndColumns in constructor of BlacoilModelEbos. Change makeOverlapRowsInvalid, by looping over precalculated inddies instead of grid
* Better formatting
it is possible that a dune entity vanishes if its iterator gets out of
scope. Whether this is a problem or not seems to be be highly depend
on the used configuration...
also, clean them up a bit:
- do not use the intensive quantities cache directly anymore. (i.e.,
that code should now work if the IQ cache is disabled)
- do not fiddle with the global Jacobian matrix and residual vector
directly. Instead, implement the water fluxes to the reservoir as a
source term like wells.
one thing that did not become fully clear to me is if each aquifer
ought to be assumed to be in contact with the whole reservoir or just
a few cells on the boundary. The current implementation goes down the
former path, while, without any deeper knowledge, I would rather
suppose that the latter applies. maybe my understanding of this is
just too limited, though.
This is to preserve current behaviour. Infinity is used in the test
currently, rather than the provided parameter (that is only used for
mass balance/flux equations).
also, add a "reading deck" output. The idea is to make `flow`'s
behaviour less surprising by preventing people from thinking that
nothing happens after starting `flow` for a large deck.
so far, the actual specializations of the simulator were compiled into
the `libopmsimulators` library and the build of the glue code
(`flow.cpp`) thus needed to be deferred until the library was fully
built. Since the compilation of the glue code requires a full property
hierarchy for handling command line parameters, this arrangement
significantly increases the build time for systems with a sufficient
number of parallel build processes. ("sufficient" here means 8 or more
threads, i.e., a quadcore system with hyperthreading is sufficient
provided that it has enough main memory.)
the new approach is not to include these objects in
`libopmsimulators`, but to directly deal with them in the `flow`
binary. this allows all of them and the glue code to be compiled in
parallel.
compilation time on my machine before this change:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
Scanning dependencies of target opmsimulators
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_gasoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_blackoil.cpp.o
[ 2%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_solvent.cpp.o
[ 4%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_polymer.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_energy.cpp.o
[ 6%] Building CXX object CMakeFiles/opmsimulators.dir/opm/simulators/flow_ebos_oilwater_polymer.cpp.o
[ 6%] Linking CXX static library lib/libopmsimulators.a
[ 97%] Built target opmsimulators
Scanning dependencies of target flow
[100%] Building CXX object CMakeFiles/flow.dir/examples/flow.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m45.692s
user 8m47.195s
sys 0m11.533s
```
after:
```
> touch ../opm/autodiff/BlackoilModelEbos.hpp; time make -j32 flow 2> /dev/null
[ 91%] Built target opmsimulators
Scanning dependencies of target flow
[ 93%] Building CXX object CMakeFiles/flow.dir/flow/flow.cpp.o
[ 95%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_gasoil.cpp.o
[ 97%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_polymer.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_oilwater.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_solvent.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_blackoil.cpp.o
[100%] Building CXX object CMakeFiles/flow.dir/flow/flow_ebos_energy.cpp.o
[100%] Linking CXX executable bin/flow
[100%] Built target flow
real 1m21.597s
user 8m49.476s
sys 0m10.973s
```
(this corresponds to a ~20% reduction of the time spend on waiting for
the compiler.)
The problem was only present if UMFPack was not found and therefore
FLOW_SUPPORT_AMG was defined to true. In that case we experienced compile
errors in a source branch that would never be executed. Therefore we remove
the code there and throw an exception.
i.e., mine (openSuse Tumbleweed). the problem seems to be that the
specialization of `ISTLSolver::constructAMGPrecond()` is ambiguous and
some compilers seem to be more strict about this than others. Simply
removing the problematic method seems to work fine.
That said, for non-legacy `flow` this codepath is not taken at runtime
anyway because the `ISTLSolverEbos` class is used!?
