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.
Restores the original cwd after each unittest in test_basic.py. Also
simplifies add_test() in python/simulators/CMakeLists.txt such that the
Bash script wrapper run-python-tests.sh is no longer needed to run the
tests.
With this, a slightly more sophisticated procedure is used for well rate intialization.
Since it changes existing results, it defaults to false, giving the existing behaviour.
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.
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 8e4f748 in PR #2403 and PR #2444 and continues
the work in #2690 implementing Python bindings to the flow simulator.
The Python step() method advances the simulator one report step. Before
calling step() for the first time, step_init() must have been called.
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.
That was removed before in lieu of the fraction of cells that
violate CNV.
This change should make the results as before unless somebody changes
maxStrictIter or RelaxedMaxPvFraction
Previously we used relaxed tolerance once a certain number of Newton
steps was exceeded. Now we check for all cells violating CNV locally
and if their pore volume is less than a certaun fraction (default 3%)
we use the relaxed tolerance (default: 1e9)
Original idea originated from Norce.
A resubmission of commit bb20804 in PR #2403 and PR #2442 to work with the
current master.
Continues the work in #2619 and #2631 to refactor main simulation loop in
flow to work with the Python bindings.
The run() method in SimulatorFullyImplicitBlackoilEbos.hpp is refactored
in preparation for the implementation of a Python step() function in a
later commit. Currently run() is called from runSimulatorInitOrRun() in
FlowMainEbos.hpp using the runSimulatorRunCallback_(). Later, there
will be other callbacks like runSimulatorStepInitCallback_(), and
runSimulatorStepCallback_(), that will need to call different parts of
the code in run(). The run() function is thus refactored into run(),
runInit(), runStep(), and runLastStep(). Also, some of the local
variables in run() have to be made persistent between calls to
runStep(), this applies to variables report, solverTimer, totalTimer,
and adaptiveTimeStepping, which are made private class variables.
Previously only the master process was aware of the error and flow did
deadlock in parallel runs if there were parser errors
encountered. With this commit all processes are made aware of the
problem and flow aborts with an error code.
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.
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.
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.
