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.
