It is only used within this context and produces a warning of the
form
ISTLSolverEbos.hpp:128:25: warning: unused variable ‘gridForConn’
unless the build configures accelerator support.
Also introduce new class WellModelAsLinearOperator making a well model
into an actual Dune::LinearOperator, this prevents the TypeTag dependent
type from leaking into the type of the WellModelMatrixAdapter instantiation.
As a side benefit, the adapter classes can now adapt (i.e. combine with a
matrix operator) any linear operator.
`NEW_PROP_TAG` is now a definition and not just a declaration.
Eliminate superfluous declarations, include headers with definitions.
Make one necessary forward declaration explicit.
boost::property_try::get without a defaults throws an exception. As
result the nonlinear solver and timestepper think that there is a
problem with solving and chop the timnestep until they give up.
This commit fixes this by using a default and falling back to the
command line specified value for the default solvers.
For some of the scaling approaches the wrong matrix (dereferenced
nullptr) would have been used which should have resulted segmentation
faults. With this commit we add a method getMatrix() that returns the
correct one and use that for scaling.
Somehow that approach went missing in action and it is always the
same as the assembled matrix. Hence no need for that member anymore
and we remove it to prevent confusion.
In this case matrix_ is a nullptr and noGhostMat_ is the optimized
matrix to use. Before this commit we experienced a segmentation fault
as the nullptr was dereferenced and passed to the solver.
Previously, one had to call a seperate binary called
flow_blackoil_dunecpr. Unforntunately, that was only built if users
requested that the tests (`-DBUILD_TESTING=ON`) and the flow
variants (`-DBUILD_FLOW_VARIANTS=ON`) should be built. In addition
it would use a slightly different nonlinear solver implementation.
With this commit flow can be asked to either use
CPR (`--use-cpr=true --matrix-add-well-contributions=true`) or to use
the flexible solvers bx setting the `--linear-solver-configuration`
option. In all other cases the usual solver implementations are still
used.
Note that the flexible solvers still need
`--matrix-add-well-contributions=true` and hence cannot cope with
multi-segment wells.
