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.
If the user requested ILU0, the uninitialized valued caused an
arbritrary (quite high) fill-in level to be used which stalled the
computation and exhausted memory when running parallel.
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 all the ranks print linear solver statistics in verbose
mode which cluttered the output in parallel runs. Now only rank 0
will print like it should be.
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.
The default was 0 for flow and 3 for flow_blackoil_dunecpr. Now we
always use 3. This is safe as it will not be used for any other
solvers than the flexible ones.
as there already is a specialization for an arbitrary Block
and that one leads to compile errors because we redefine it
in OPM (and miss some other specializations for Opm:MatrixBlock,
e.g. isNumber).
