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.
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.
For the Python interface's usage (as opposed to the usage by e.g.
flow.cpp), we do not neccessarily want to run the whole simulation by
calling run(), it is also useful to just run one report step at a time.
According to these different usage scenarios, main_() is refactored into
initialize_() and dispatch_() as a preparatory step for implementing the
Python interface (to be presented in a later PR).
Fixup usage of Deck, EclipseState, Schedule, and SummaryConfig to take
into account the class variables deck_, eclipseState_, schedule_, and
summaryConfig_. These variables might initially be empty (nullptr) when
the object is constructed by calling Main(argc, argv) from flow.cpp,
flow_blackoil_dunecpr.cpp, flow_onephase.cpp, or
flow_onephase_energy.cpp. However, when Opm::Main is constructed from the
Python interface code (to be implemented in a later PR) by using the
constructor Main(argc, argv, deck, eclispeState, schedule, summaryConfig)
the variables will not be intially empty.
Adapting Main.hpp to be called from Python interface, Part 1.
Building on PR #2521 and PR #2535, we gradually adapt Main.hpp for
being called from the Python interface (to be committed in a later PR)
to the flow executable. This PR introduces a new constructor for class
Opm::Main that takes a Deck, EclipseState, Schedule, and SummaryConfig
as arguments. It also introduces some new class variables that will be
useful when the main_() method is split up (in a later commit).
Some of the functions in Main.hpp do not need to be guarded by a
\#ifndef OPM_FLOW_MAIN
Since they are template functions, they will not be included in the
code unless explicitly instantiated.
Addresses the comments in PR #2521 regarding code duplication in
Main.hpp and flow_tag.hpp. This PR merges the code in flow_tag.hpp
into Main.hpp such that flow_tag.hpp can be eliminated (will be done
in the next PR).
According to private discussion with @joakim-hove PR #2516 is splitted into
smaller parts to facilitate review and a quicker merge into master.
As mentioned in PR #2516, main() in flow.cpp is refactored to address
the comments on PR #2127 and as preparation for implementing the Python
bindings described in PR #2403.
