There cannot happen any collective blocking communication within a
parallel try-catch clause if exceptions might be thrown before the
communication. The communication has to either be reached by all
processes or no processes.
Although not declared as such, prepareTimeStep seems to be an internal
function (despite usage in a test) and hence error control can be done
in code calling it.
There was the following problem with the try-catch approach taken:
The calling site `BlackoilWellModel::assemble` looked like this:
```
OPM_BEGIN_PARALLEL_TRY_CATCH();
{
if (iterationIdx == 0) {
calculateExplicitQuantities(local_deferredLogger); // no parallel try-catch
prepareTimeStep(local_deferredLogger); //includes parallel try-catch
}
updateWellControls(local_deferredLogger, /* check group controls */ true);
// Set the well primary variables based on the value of well solutions
initPrimaryVariablesEvaluation();
maybeDoGasLiftOptimize(local_deferredLogger);
assembleWellEq(dt, local_deferredLogger);
}
OPM_END_PARALLEL_TRY_CATCH_LOG(local_deferredLogger, "assemble() failed: ",
terminal_output_);
```
calculateExplicitQuantities had no parallel-try-catch clause inside,
but prepareTimeStep had one.
Unfortunately, calculateExplicitQuantities might throw (on some
processors). In that case non-throwing processors will try to trigger a
collective communication (to check for errors) in
prepareTimeStep. While the one throwing will move to the
OPM_END_PARALLEL_TRY_CATCH_LOG macro at the end and also trigger a different
collective communication. Booom, we have a deadlock.
With this patch there is no (nested parallel)-try-catch clause in the
functions called. (And if an exception is thrown in prepareTimeStep, it
will be logged as being an assemble failure).
The other option would have been to add parallel-try-catch clauses
to all functions called. That would have created a lot more
synchronization points limiting scalability even further.
Not a big fan of Macros but here at least they seem ot be the only
option. The problem is that the catch clauses must all catch the same
exceptions that have a entry in ExceptionType, because they might be
nested. In addition we did not have a catch all clause, which is added
now and is needed in case a called method throws an unexpected exception.
Previously, exceptions happening at this stage have deadlocked
flow. E.g. UniformTabulated2DFunction in opm-material throws
a NumericalIssue if the values passed are outside the tabulated
reason. This function is e.g. called in 2-phase CO2-storage cases
during BlackoilModel::initializeWellState
BTW: This is only the first step as it is not very user friendly that
a simulation aborts at this (late) stage.
This commit protects against Opm::Well instances for which the sets
of connections are empty. In those cases, do not put entries in the
well container as there is no influence on the systems of non-linear
equations.
GasLiftGroupInfo.cpp did not include "config.h" which caused HAVE_MPI
to be undefined causing the file to be compiled with
Dune::Communication<No_Comm> instead of with
Dune::Communication<MPI_Comm>. Which later caused linking problems with files
that used MPI.
Check group limits in gas lift stage 1 to avoid adding too much ALQ which must
anyway later be removed in stage 2. This should make the optimization
more efficient for small ALQ increment values. Also adds MPI support.
This commit includes the shut wells in 'wells_ecl_' and expands the
PI/II value calculation to apply to those shut wells too. With this
in place we are able to run cases that have a 'WELPI' keyword before
the well opens, even at the very first report step.
In particular, apply explicit default constructors to most data
members and push initialisation to initialiser list if convenient.
While here, also split long lines and apply const in more places.
Finally, reset well- and connection-level PI values to zero in
WellState::shutWell(). This is in preparation of including shut
wells in BlackoilWellModel's internal state.
Extends PR #2824 to include support for GLIFTOPT (item 2, maximum lift
gas supply for a group) and group production constraints.
The optimization is split into two phases. First the wells are optimized
separately (as in PR #2824). In this phase LIFTOPT and WLIFTOPT constraints
(e.g. maxmimum lift gas injection for a well, minimum economic gradient) are
considered together with well production constraints.
Then, in the next phase the wells are optimized in groups. Here, the ALQ
distribution from the first phase is used as a starting point. If a group
has any production rate constraints, and/or a limit on its total rate of
lift gas supply, lift gas is redistributed to the wells that gain the most
benefit from it by considering which wells that currently has the largest
weighted incremental gradient (i.e. increase in oil rate compared to
increase in ALQ).
This commit sets the 'data::Well::dynamicStatus' based on the
dynamically updated 'Schedule' object (i.e., from ACTIONX and
similar) and the results of well/operability testing (WECON and/or
WTEST). If a well is closed due to economic limits (WECON) we still
provide summary-style data at the timestep that closed the well, but
omit this data at later steps until the well reopens.
We add a new parameter to WellState::report() to distinguish these
situations.
This is in preparation of making the 'BlackoilWellModel' manage both
open and shut wells alike.
Coalesce blocks with same conditions, split long lines, and apply
'const' where appropriate. While here, also tighten the "rate = 0"
criterion to include denormalised numbers.
With this commit the guiderate logic used for the production groups is also used for injectors
This allows for setting guiderates explicit at different group levels
Only RATE, NETV and VOID guiderate type is suppored.
When an ACTIONX has evaluated to True we inspect the keyword payload and if it
contains WELPI we query the well model for current wellpi values and pass that
along as context to the Schedule::applyAction()
Some of our computations are heavily serial and need a complete
representation of the data attached to all perforation no matter
whether a perforation lives on the local partition or not. This commit
adds a factory that allows to easily create such a representaion and
helps writing data back to the local representation.
This commit implements the WELPI feature. We calculate new PI/II
values for all wells in the event of a WELPI request and use those
values for well-specific WELPI request, to calculate CTF scaling
factors. We then apply those factors to all subsequent editions of
the well provided the connection factors are eligible for
WELPI-based rescaling.
If we trigger a rescaling event we also reset the WellState's
internal copies of the CTFs and reinitialize the Well PI calculators
to ensure the rescaling takes effect immediately. Since we rely on
PI values being available at the end of each time step we must also
take care to forward those values from the WellState of one report
step to the WellState of the next report step.
Finally, take care not to redo a WELPI scaling if we've already
performed the scaling operation and restart a report step. This,
in turn, happens if WELPI is requested on the first report step.
The B matrix is basically a component-wise multiplication
with a vector followed by a parallel reduction. We do that
reduction to all ranks computing for the well to save the
broadcast when applying C^T.
BlackoilWellModel now stores an instance of this class for each
well. Inside that class there is a custom communicator that only
contains ranks that will have local cells perforated by the well.
This will be used in the application of the distributed well operator.
This is another small step in the direction of distributed wells,
but it should be safe to merge this (note creation of the custom
communicators is a collective operation in MPI but done only once).
This commit adds a new helper function,
WellInterfacePtr createWellPointer(wellID, reportStep) const
which is responsible for creating appropriately typed derived well
pointers depending on well types (multi-segment vs. standard).
This, in turn, allows us to centralise this logic and use the same
factory function both when creating the 'well_container_' and when
forming the well-test objects.
Finally, this helper will become useful for calculating PI/II values
of shut/stopped wells in the context of WELPI.
The original code assumed that
well_container_.size() == numLocalWells()
This assumption does not hold when wells open/shut dynamically in
the context of WECON and/or WTEST.
Switch to indexing into the 'prod_index_calc_' vector using the
well's own linear index instead of manually advancing iterators.
Pointy Hat: [at]bska
This commit ensures that we calculate the well and connection level
per-phase steady-state productivity index (PI) at the end of a
completed time step (triggered from endTimeStep()).
We add a new data member,
BlackoilWellModel<>::prod_index_calc_
which holds one WellProdIndexCalculator for each of the process'
local wells and a new interface member function
WellInterface::updateProductivityIndex
which uses a per-well PI calculator to actually compute the PI
values and store those in the WellState. Implement this member
function for both StandardWell and MultisegmentWell. Were it not
for 'getMobility' existing only in the derived classes, the two
equal implementations could be merged and moved to the interface.
We also add a new data member to the WellStateFullyImplicitBlackoil
to hold the connection-level PI values. Finally, remove the
conditional PI calculation from StandardWell's well equation
assembly routine.
In serial we use the first cell of the first well to determine the
pvt region index for a group. Previously, we used the first cell of
the first local well in a parallel run. Unfortunately that may lead
to different pvt region indices being used for the same goup on
different processes.
We fix this by using the same approach in parallel as we already use
in serial. For this we use Well::seqIndex() to determine the needed
ordering.
and use it in the WellInterface instead of creating a vector
with these indices there. The original approach recreates
information in another path of the well and assumes that all
connections are in a process's local partition. That assumption
does not hold any more for distributed wells.
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.
Implements gas lift optimization for a single StandardWell. Support for
gas lift optimization for multi-segment wells, groups of wells and
networks is not implemented yet.
The keywords LIFTOPT, WLIFTOPT, and VFPPROD are used to supply parameters for
the optimization. Also adds support for summary output of liftgas
injection rate via keyword WGLIR.
Previously, we exported an unordered map containing all names of
wells that are not present in the local part of the grid.
As we envision to have wells that are distributed across multiple
processors, this information does not seem to be enough. We need
to be able to set up communication for each well. To do this we need
to find out who handles perforations of each well.
We now export a full list of well name together with a boolean
indicating whether it perforates local cells (vector of pair of string
and bool).
This is in preparation of adding support for outputting the network
node pressure quantity, GPR, to the summary file. In particular,
'GroupValues' is renamed to 'GroupAndNetworkValues' and has new
individual datamembers for the former group-level data and the new
node-level data.
Update BlackoilWellModel::groupData() and CollectToIORank
accordingly and bring the parallel restart facility in line with the
new layout.
This commit adds support for reporting the simulator's guiderate
values at the well and group levels to the output layer through the
wellData() and groupData() member functions. We add several new
member functions that collectively assemble the values and assign
them to objects of type Opm::data::GuideRateValue for subsequent
output to the summary and restart files.
In particular
getGuideRateValues(const Well&) const
getGuideRateValues(const Group&) const
retrieve the guiderate values for all phases for those individual
wells and groups for which the guideRate_ data member defines a
value. The most complicated function of this commit is
calculateAllGroupGuideRates
which aggregates those individual contributions from the well (leaf)
level up to the root of the group tree (the FIELD group). This
process uses an ancillary array ('up') to keep track of the parent
groups of all wells and all groups, and to ensure that we only visit
each parent group once (sort+unique on subsets of the 'up' array).
We do not currently support outputting guiderates for reservoir
voidage volume (GuideRateModel::Target::RES).
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
This commit makes the 'groupData()' function return a
map<string, Opm::data::GroupData>
object instead of a
map<string, Opm::data::GroupConstraints>
object. The 'GroupData' structure adds a level of indirection to
the current per-group summary quantities that are directly assigned
by the simulator. While here, also move the assignment of the
current group constraints/control values out to a separate helper
to reduce the body of the per-group loop in 'groupData()'.
This is in preparation of adding support for reporting group-level
production/injection guiderates (Gx[IP]GR) to the summary file.
1) Only check GCONSALE limits at the end of a timestep. NB. The simulator still throws if some of the limits are violated
2) BUGFIX: don't remove gas consumption twice
- Communicate all well rates.
- When changing controls, modify rates to satisfy failed constraint.
- Ensure targets are positive.
- Always solve for potentials for MSW (temporary fix).
