Expect non-reference type shared pointers arguments instead of references
to shared pointer. This will make it clear to the caller that the called
function is making a copy of the pointer for its own use and not trying
to modify the original pointer of the caller.
Adds a new constructor to Main.hpp that takes shared pointers to Deck,
EclipseState, Schedule, and SummaryConfig. This makes it possible to
share these variables with Python without worrying about lifetime issues
of the underlying C++ objects. For example, a Python script can first
create an opm.io.schedule.Schedule object which is modified from Python.
Then, assume the same Python script creates an
opm.simulators.BlackOilSimulator which is initialized with the same
schedule object. Since the underlying C++ object is a shared pointer,
the Schedule object in Python may go out of scope (get deleted by Python)
without having the C++ schedule object being deleted. And the Python
BlackOilSimulator may continue to be used after the Python Schedule object
has been deleted since it still has a valid C++ schedule object.
Executable is named flow_distribute_z and uses the external
loadbalancing information. It can be used to test the distributed
standard wells on SPE9 with 4 or more processes.
Currently the simulator creats the polyhedreal grid from an eclGrid from opm-common
TODO
- make it possible to create the grid directly from DGF or MRST format
- fix issue on norne.
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.
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.
`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.
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.
Refactors away flow_tag.hpp by having flow_blackoil_dunecpr.cpp,
flow_onephase.cpp, and flow_onephase_energy.cpp use the updated Main.hpp
from a previous pull request. This will eliminate the previous code
duplication in Main.hpp and flow_tag.hpp discussed in PR #2521.
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.
The previous was "file" which resulted in runtime errors
like
Program threw an exception: No linear-solver-configuration-json-file given for linear-solver-configuration=file
