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).
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.
This commit introduces a new helper class,
Opm::EQUIL::Details::PhaseSaturations<>
that subsumes the responsibility of the existing helper function
Opm::EQUIL::phaseSaturations<>()
and generalises that functionality to arbitrary depth points within
single cells. This is in preparation of adding support for the N<0
case of the initial fluid in place procedure defined in the EQUIL
keyword. The class consumes an already equlibrated pressure table
for the pertinent equilibration region, calculates capillary
pressure values and inverts Pc curves to derive saturation values.
If the capillary pressure curves are constant within a cell, then a
simple depth consideration with respect to the implied sharp phase
interface is used to derive saturation values. We also preserve
existing support for SWATINIT-type initialisation of the water
saturation field.
Switch InitialStateComputer<>::calcPressSatRsRv() over to using the
pressure and saturation helper classes instead of the original
helper functions since this provides additional control. Also
remove those helper functions to reduce risk of confusion over which
method to use. Update the unit tests accordingly.
These unit test were previously disabled. While here, also fix some
'missing declaration' errors by putting the test functions into a
private namespace.
At some point we should rewrite this to use Boost.Test.
This commit is the first step of several that implements ECLIPSE's
"accurate fluid-in-place" model initialization procedure based on
subdividing the vertical range/extent of individual cells. This
first step puts the O/G/W phase-pressure calculation into a helper
class,
Opm::EQUIL::Details::PressureTable<>
through which phase pressure values can be calculated at abritrary
depths rather than just at the cell centre depths. In other words,
this helper class extends and subsumes the responsibilities of the
existing helper functions
Opm::EQUIL::Details::PhasePressure::assign()
Opm::EQUIL::Details::PhasePressure::oil()
Opm::EQUIL::Details::PhasePressure::gas()
Opm::EQUIL::Details::PhasePressure::water()
We still use the same ODE-based evaluation procedure for the phase
pressures and the equilibrateOWG() helper function still computes
the phase pressure values at cell centre depths only.
That, in turn, corresponds to the "N = 0" case (steady state) of the
basic equilibration facility.
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).
