Remove left parenthesis character left over from transitioning to
the type-based parameter system. The '(' produced a build failure
which only manifested in debug builds.
Thanks to Håkon Hægland for bringing the issue to our attention.
Especially, grab a copy of the "oldControl" to avoid reading through
a reference for which the underlying object is reset in
setCurrent*GroupControl()
This in turn avoids generating confusing diagnostic messages of the
form
Switching production control mode for group G from FLD to FLD
These codes are reimplemented in the ebos simulator and should
be reused, instead. This commit factilitates this and starts
reusing the logging setup code in ebos. Hence reduces code duplication.
Before this we had a set of external*_ variabales (unique_ptrs), a set of
internal_*_ variables (unique_ptrs) and another set of pointers that
point to the pointers actually used. That seemed a bit much. With this
commit skip the internal variables and use unique_ptrs for all
others. In the constructor either the external*_ gets moved or the
objects are directly created as unique_ptrs.
We resort to consistently use unique_ptrs in EclBaseVanguard for
the data read from ECL files or set externally. This means that
during the simulation EclBaseVanguard owns this data and not Main
or the ebos setup functions. This ownership transfer becomes
transparent due to std::move.
This came up when trying to fix the parallel runs of ebos and during
that removing some code duplication.
A resubmission of commit 11eaa3d7 in PR #2403 and PR #2443 and continues
the work in #2555 implementing Python bindings to the flow simulator.
The step_init() method initializes the simulation. It is required for the
Python script to run step_init() before calling the step() method (which
will be implemented in a later commit).
Clarify usage of member variables in FlowMainEbos.hpp by prefixing with
this->.
Also rebased PR on the current master, and updated
flow_ebos_oilwater_brine.cpp according to the PR.
Make Opm::FlowMainEbos capture the variables argc, argv, outputCout, and
outputFiles. Passing the variables to the constructor and saving them as
class variables in Opm::FlowMainEbos makes the implementation of the
Python interface simpler. For example, the step_init() method does not
need to ask Opm::Main about the values of the variables when it needs to
run execute() in FlowMainEbos.
Another advantage of this refactoring could be that less variables needs
to be passed around from Opm::Main, to flow_ebos_xxx.cpp, and then again
to FlowMainEbos.
