A resubmission of commit b25f489 in PR #2403 and PR #2441 to work with
the current master.
Continues the work in PR #2619 to refactor FlowMainEbos.hpp to work with
the Python bindings.
We need to refactor runSimulator() to avoid code duplication when
executeStepInit() is implemented (see later commit). Here, runSimulator()
is refactored into a runSimulatorInitOrRun() that takes a callback
function. When runSimulatorInit() is implemented it will pass a different
callback that only initializes the simulator. Currently, runSimulator()
passes the callback runSimulatorRunCallback_() which runs the whole
simulation. The code outputting the simulation summary in runSimulator()
is also refactored into a runSimulatorAfterSim_() method.
`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.
Currently, execute() calls runSimulator() to run the simulation. When
the Python step_init() is implemented (see a later commit), it will
instead call an executeStepInit() that will need to do the same
initialization as in execute() except that it should call a
runSimulatorInit() instead of runSimulator(). In order to avoid code
duplication for execute() and executeStepInit(), execute() is here
refactored into an execute_() method.
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.
NOTE: this pull request depends on #2555 which should be merged first.
A rewrite of the outdated PR #2543.
Refactors flow_ebos_blackoil.cpp such that we can choose not to execute
the whole simulation using the flowEbosBlackoilMain() function but
instead only initialize by calling flowEbosBlackoilMainInit(). This is
necessary to implement a Python step() method that can advance the
simulator one report step at a time.
Also adds a method initFlowEbosBlackoil() to Main.hpp that can be used
directly from the Python interface's BlackOilSimulator object to gain
access to the FlowMainEbos object before it has initialized the
simulation main loop.
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).
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.
