Use the Python module sphinx-versioned-docs to get versioned docs.
Currently, there is only a version for the HEAD of the master branch
but release versions can be added later by specifying a release tag.
Added sphinx documentation for the opm.simulators.BlackOilSimulator
Python module. Added GitHub action workflow to deploy sphinx
documentation to GitHub Pages.
When testing a gaslift well under THP control, if the
well does not converge with maximum alq, try to reduce alq
in increments until well equations converge.
It only makes sense to try to optimize the distribution of lift gas if
the amount of lift gas is constrained either by the maximum allowed
gaslift or total gas or the group is under individual control.
Moves the updateRelperms() method in BlackOilInstensiveQuantities in
opm-models to the EclProblem class and its parent MultiPhaseBaseProblem.
This is a more natural place for this method and it avoids having to
include EclMaterialManager into the BlackOilInstensiveQuantities.
Moves the updateRelperms() method in BlackOilInstensiveQuantities to the
Problem class. This is a more natural place for this method and it avoids
including EclMaterialManager into the BlackOilInstensiveQuantities. The
DirectionalMobility struct is moved to a separate file such that it can be
include from both the Problem files and the BlackOilInstensiveQuanMove
updateRelperms() to the problem class
Define a method materialLawManagerPtr() that returns a nullpointer
to EclMaterialLawManager, but that can be overridden in derived classes
e.g. EclProblem
This is used by blackoilintensivequantities.hh. Further, for other
problems derived from MultiPhaseBaseProblem, that base class will
return a null pointer such that problems that do not override the
materialLawManagerPtr() method still can use the blackoil intensive
quantitites (which in the case of directional relative permeabilities
makes use of the problem reference to access the materialLawManager)
Convert the Python opm package from a regular package to a namespace
package such that opm-simulators and opm-common can contribute to the
package from different filesystem paths. In this way, the two packages
opm.simulators and opm.io (in opm-common) can have a different parent
filesystem path.
Remove SYSTEM argument for pybind11_add_module() if cmake version is
greater than 3.12. It appears that this argument has been deprecated
and also removed by the new FindPython mode in the cmake tools for
pybind11.
Assign a maximum ALQ value to each GLIFT producer when doing well testing
in beginTimeStep(). This allows the well to be considered open. Then,
later in the timestep, when assemble() is called, the full gas lift
optimization procedure can adjust the ALQ to its correct value.
It is also observed that in some cases when gas lift is switched off by
setting ALQ to zero, and later in the schedule is switched back on again,
it might not be possible to determine bhp from thp for low small ALQ values.
Instead of aborting the gas lift optimization, we should try increasing
ALQ until we get convergence or until the maximum ALQ for the well is
reached.
Refer to opm-common/pull #2971. In order to use the new constructor
proposed in that PR, the constructor must now be passed a boolean
variable signalling if gaslift is active.
Renames some methods and variables to reflect that the well is no
longer necessarily a StandardWell. It can be either a MultisegmentWell
or a StandardWell. This should avoid confusion about the nature of
the variable.
Introduces two new data types BasicRates and LimitedRates to capture
oil, gas, and water rates, and whether they have been limited by well
or group targets. This reduces the number of variables that are passed
to and returned from various methods and thus makes the code easier to
read.
The headers BlackoilWellModel.hpp, StandardWell.hpp,and WellInterface.hpp
all include various GasLift*.hpp headers directly. That means that any
client code that uses those well-related headers will need to have the
GasLift* headers available too.
Also sorts the headers under opm/simulators/wells to make the it easier
to read.
Introduces a gaslift debugging variable in ALQState in WellState. This
variable will persist between timesteps in contrast to when debugging
variables are defined in GasLiftSingleWell, GasLiftGroupState, or GasLiftStage2.
Currently only an integer variable debug_counter is added to ALQState,
which can be used as follows: First debugging is switched on globally
for BlackOilWellModel, GasLiftSingleWell, GasLiftGroupState, and
GasLiftStage2 by setting glift_debug to a true value in BlackOilWellModelGeneric.
Then, the following debugging code can be added to e.g. one of
GasLiftSingleWell, GasLiftGroupState, or GasLiftStage2 :
auto count = debugUpdateGlobalCounter_();
if (count == some_integer) {
displayDebugMessage_("stop here");
}
Here, the integer "some_integer" is determined typically by looking at
the debugging output of a previous run. This can be done since the
call to debugUpdateGlobalCounter_() will print out the current value
of the counter and then increment the counter by one. And it will be
easy to recognize these values in the debug ouput. If you find a place
in the output that looks suspect, just take a note of the counter
value in the output around that point and insert the value for
"some_integer", then after recompiling the code with the desired value
for "some_integer", it is now easy to set a breakpoint in GDB at the
line
displayDebugMessage_("stop here").
shown in the above snippet. This should improve the ability to quickly
to set a breakpoint in GDB around at a given time and point in the simulation.
Refactors getOilRateWithLimit_(), getGasRateWithLimit_(), and
getWaterRateWithLimit_() in GasLiftSingleWellGeneric.cpp. The
common part of the methods is split out into a new method called
getRateWithLimit_(). The purpose of the refactorization is to reduce
reptetive code and make the code easier to maintain.
This is in agreement with C++ Core Guidelines. A member function should
be marked const unless it changes the object’s observable state. This
gives a more precise statement of design intent, better readability, more
errors caught by the compiler, and sometimes more optimization opportunities.
Refactor getOilRateWithGroupLimit_(), getGasRateWithGroupLimit_(),
getWaterRateWithGroupLimit_(), and getLiquidRateWithGroupLimit_() into
a single generic method called getRateWithGroupLimit_().
Consider all groups when reducing oil rate to group limits.
The current code just checks the first group limit in the set.
But there might be groups later in the set with more restrictive
limits, causing the oil rate to be reduced more than the first
limit.
As discussed in PR #3728, it is better to move the two methods
reduceALQtoGroupTarget() and checkGroupTargetsViolated() from
OptimizeState to the parent class, then we do not have to abuse
OptimizeState in maybeAdjustALQbeforeOptimizeLoop_() just to call
reduceALQtoGroupTarget().
Also fixes a typo (as discussed in PR #3729) in reduceALQtoGrouptTarget()
where the water rate is updated with the gas flow rate instead of the
water flow rate. Should be like this:
water_rate = -potentials[this->parent.water_pos_];
instead of
water_rate = -potentials[this->parent.gas_pos_];
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.
Håkon Hægland