Update Well Topology if Triggered From ACTIONX

[bska]

This commit adds a new flag data member,

bool wellStructureChangedDynamically_

to the generic black-oil well model. This flag captures the

well_structure_changed

value from the SimulatorUpdate structure in the updateEclWells() member function. Then, in BlackoilWellModel::beginTimeStep(), we key a well structure update off this flag when set. This, in turn, enables creating or opening wells as a result of an ACTIONX block updating the structure in the middle of a report step.

[bska]

As an example of the effect, the figure below compares the field pressure (FPR) and well level water injection rate (WWIR) of injector WI01 from ACTIONX_WCONINJE in OPM-Tests when run with

--solver-max-time-step-in-days=1.0

using the current master sources (_MASTER) and this PR (_DEV). Action ACT-02 triggers on the 12th of July 2019 in both runs, as a result of the field pressure dropping below the threshold value of 230 bars, but only the current PR immediately opens the WI01 injector. In the current master sources the WI01 injector is not opened until the start of the next report step on the 1st of August 2019. Both of these runs were parallel, using mpirun -np 5, on my local development machine.

---

[bska]

jenkins build this please

[blattms]

Looks good to me (assuming that we catch all those structure changes), I would have merged this as it seems to fit urgent issues, but it is marked as WIP and I assume that there is a reason for that.

[bska]

jenkins build this please

[blattms]

Thanks for the clarification. This now triggered a thought on my side:

I have previously been wondering why this works in parallel when it seemed that all code works only on the local process without any communication. I concluded that is probably OK because the state that the ACTIONX evaluates is shared between the processes (and I assumed that the wells triggering the action are a superset of the affected wells).

Now this is not really the case, when an action gets triggered for a set wells but it affects another set of wells. In a parallel run the set of affected wells might only contain wells that do not perforate local wells while the triggering set might have wells which perforate local cells in it, and vice versa.

Could it be that in parallel we correctly evaluate the actions for local wells, but if the affected well is on another process (no perforated cell on this process) then we do nothing? Maybe this did not happen before because at report steps we do the necessary computation implicitly?

[bska]

I believe that the current action handling logic is correct, even in parallel, although there may be issues if the run uses distributed wells. I haven't analysed that case completely. My reasoning is as follows

1. The call to EclActionHandler::applyActions() happens very late in EclProblem::endTimeStep() at which point we have a converged solution for the time step.
2. Right before that call, we invoke EclWriter::evalSummaryState(). This computes new values for every summary vector in the run, including those vectors which are "only" needed for action handling. Moreover, each rank has the same–technically just equal/equivalent–SummaryState object at the end of the evalSummaryState() call due to explicit MPI logic at the end of that function call.
3. The ACTIONX triggers are always phrased purely in terms of those summary vectors, meaning each MPI rank will evaluate the conditions the same way, irrespective of which wells happen to be active on the current rank.
4. When running the action block, we call back into the Schedule object and the sets of matching_wells and wellpi wells will both be the same on all ranks, meaning Schedule::applyAction() will perform the same operation on all ranks and compute the same sim_update, including its affected wells, on all ranks.
5. Finally, EclActionHandler::applyActions() calls EclActionHandler::applySimulatorUpdate() which in turn invokes the well model's updateEclWells() member function. The set of affected wells is the same on all ranks. Member function updateEclWells(), however, filters that list depending on which wells are active on the current rank so each rank applies updates only to those wells it actively knows about.

All in all I believe that this means each rank computes the correct set of mathcing and affected wells for each action, but only mutates the local wells.

[bska]

jenkins build this please

[bska]

jenkins build this update_data please

[bska]

jenkins build this opm-tests=1085 please

[bska]

The new reference solutions have been installed on the CI system. Merging per prior approval.

[blattms]

@bska In retrospect, I have questions about this (because I have similar problems):

The reason for the problem (changes occur to the wells only on the next report step) was, that these changes happen(ed) in the simulator due to Events signaled by the schedule. This happens at the next report step (because that is where the schedule is changed and that is where we query for events).
Is it correct that with this change the event about the well changing will still be triggered on the next report step?

Probably not a real problem here, because it is just additional work, but does not change anything, but for other keywords (e.g. NEXTSTEP) it might be.