When there is some events happen to a well, we use the control mode
from the DECK, and update the WellState based on the new control model.
Otherwise, we can use the control mode from the previous well state,
and keep the values from the previous well state as an intial guess.
* 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.
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!?
