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).
A simplified version of PR #2518 that uses a deck filename to construct
the simulator.
After private discussion with @joakim-hove it was decided that the
construction of the blackoil simulator from Python using deck,
ecliseState, schedule and summaryConfig as constructor arguments from
\#2518 should be replaced by a constructor taking only the deck filename
as parameter.
A rewrite of the Python bindings for the blackoil simulator using
pybind11 as introduced in PR #2127. The new version uses the
refactored flow.cpp introduced in PR #2516 and thus avoids duplication
of the code in simulators.cpp.
This PR will be the starting point for implementing the Python bindings
introduced in PR #2403.
Without this, properties set in the static variants of flow such as
flow_blackoil_dunecpr.cpp will be honored in the run. However, the
text for '--help' and the property printout in the .DBG file will not
reflect the true type tag, but the default.
This bug was added during the recent refactoring of all Flow variants
to use the same initialization and setup code.
1) Only check GCONSALE limits at the end of a timestep. NB. The simulator still throws if some of the limits are violated
2) BUGFIX: don't remove gas consumption twice
