group control is NONE if the group does not contribute to the group target of any well

[GitPaean]

This PR only handles the group production control. It is possible that we can do the same for the group injecting controls, while it is not the aim in this development.

In a group hierarchy, there can be different group constraints specified for each group. Depending on the simulation situations, some constraints are restricting the wells' production, and typically, many of the group constraints not active or enforcing any restriction to wells (it also means no group either, since there is not wells got the production target from this group, this is a assumption most likely correct). For those groups, the group control mode (GMCTP, or FMCTP for FIELD) should be NONE.

In the master branch, as long as a group is under RATE control, it can not return to NONE mode anymore. In this PR, we check this at the end of the time step, and updates the production control modes for the groups that are not enforcing constraints to wells to be NONE.

Ideally, we can do it for each Newton iteration, while for now, we do it at the end of the time step. At the early stage of the Newton iteration, the situation can be rather random, updating for the NONE group control mode turns out to be very problematic from some earlier tests. We can test in a later development after this PR.

The last commit ff3eba3 makes an exception for the gas lift optimization groups, which rely on the group control not being NONE to perform the gas lift optimization. Some adjustment might be needed based on future testing.

[GitPaean]

jenkins build this failure_report please

[GitPaean]

it looks like this PR is basically producing consistent results with #6585 .

since #6585 needs a human specified tolerance, I think if the SingleWellState::group_target is updated properly, the approach in this PR is better.

At the same time, we still need to figure out why the regression with model4_udq_group and uda_model5_stdw.

[GitPaean]

For the case 6_UDA_MODEL5_STDW, only look at the production controls and rates (this PR only handles production related).

the well C-1H has regression at the beginning of the February 2020.

group tree looks like

GCONPROD

310 GCONPROD
311  'FIELD'   'ORAT'  'FU_MAXO'  1*  FU_MAXG 1*  'RATE' /
312  'M5N'     'ORAT'  'FU_MAXON' 3*   'RATE' /
313 /

WCONPROD

295 WCONPROD
296 --  Well_name  Status  Ctrl  Orate   Wrate  Grate Lrate   RFV  FBHP   WHP  VFP Glift
297    'B-1H'      OPEN    ORAT  WU_MAXO  1*     1*    3000.0  1*   100.0  30   1   100000.0  /
298    'B-2H'      SHUT    ORAT  WU_MAXO  1*     1*    3000.0  1*   100.0  30   1   1*  /
299    'B-3H'      OPEN    ORAT  WU_MAXO  1*     1*    3000.0  1*   100.0  30   1   1*  /
300    'C-1H'      OPEN    ORAT  WU_MAXO  1*     1*    3000.0  1*   100.0  30   1   1*  /
301    'C-2H'      SHUT    ORAT  WU_MAXO  1*     1*    3000.0  1*   100.0  30   1   1*  /
302 /

at 1/FEB/2020,

ORAT for FIELD is 2500.

ORAT for M5N changes from 500 to 2500.
ORAT for C-1H is 425.

ORAT for B-1H changed from 525 to 1500.
ORAT for B-3H changed from 515 to 1500.
B-2H newly opened with ORAT 500.

with master branch,

Group M5N stays at the ORAT control and well C-1H stays at the ORAT control. But the M5N is not producing its ORAT target 2500. GOPR:M5N == WOPR:C-1H == 425.
GOPR:M5S == 2500 - 425 == 2075.

with the PR

Group M5N controls changed to NONE, the well C-1H stays at the GRUP control with WOPR 355.742.
Well B-2H is at ORAT control with WOPR 500.
Wells B-1H and B-2H changes to GRUP control with WOPR of 916.529 and 727.729, respectively.

The results from this PR is most likely the more reasonable one for the change at the 01-Feb-2020.

@steink @totto82 @atgeirr please suggest if you have some comments.

[GitPaean]

The regression failure for model4_udq_group is from different time stepping besides the different output of GMCTP and FMCTP.

So far, I think the results from this PR has been reasonable.

Will begin cleaning up.

At the same time, This PR is less invasive compared with #6559 , which is too difficult due to other issues associated with group controls, for example, BHP control is used for the wells under GRUP control while could not find any group target, and also the counting and limitation of the group control switching times.

The PR will serve as a temporary solution for a specific issue (GMCTP/FMCTP summary output.)

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this please

[GitPaean]

... the last pure refactoring commit managed to remove one failure,

https://ci.opm-project.org/job/opm-simulators-PR-builder/9014/testReport/junit/(root)/mpi/compareECLFiles_flow_02_WGRUPCON/

unexpected.

[GitPaean]

jenkins build this please

[GitPaean]

... the last pure refactoring commit managed to remove one failure,

https://ci.opm-project.org/job/opm-simulators-PR-builder/9014/testReport/junit/(root)/mpi/compareECLFiles_flow_02_WGRUPCON/

unexpected.

There is some mystery about this case's regression testing behavoir and I could not figure out.

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this please

[GitPaean]

jenkins build this failure_report please

[totto82]

What is the purpose of this PR? I initially thought it was mostly for output, but upon reading the code, I became confused.

[GitPaean]

What is the purpose of this PR? I initially thought it was mostly for output, but upon reading the code, I became confused.

It is an output issue while the root cause is that the groups should be under NONE control being put under some RATE control. Basically, the control modes are not correct for those groups. From this sense, it is not just an output issue.

This PR basically checks, if a group does not have any constraints limiting the well rates, the group control mode should be NONE.

[GitPaean]

In the master branch, if we put a group with control mode under some RATE control, we can not return to NONE control anymore (usually, if not all the situations). That is what this PR is trying to provide.

[totto82]

We have the number_of_wells_under_group_control in groupstate. Couldn't that be used? If number_of_wells_under_group_control == 0 switch to NONE .

[GitPaean]

We have the number_of_wells_under_group_control in groupstate. Couldn't that be used? If number_of_wells_under_group_control == 0 switch to NONE

It is possible. I was not aware of it and will evaluate it. From the code, the evaluation of that variable is relatively heavy. Will check whether it is totally equivalent to the approach here.

[GitPaean]

We have the number_of_wells_under_group_control in groupstate. Couldn't that be used? If number_of_wells_under_group_control == 0 switch to NONE

It is possible. I was not aware of it and will evaluate it. From the code, the evaluation of that variable is relatively heavy. Will check whether it is totally equivalent to the approach here.

number_of_wells_under_group_control is not consistent with the approach in this PR, the main difference is that even there is no GCONPROD for a group, number_of_wells_under_group_control can shows it is controlling some wells, which is not the definition that it needs here.

For example, with the case,
6_UDA_MODEL5_STDW.

One output for one report step is like the following

 well C-1H is controlled by group FIELD
 well B-3H is controlled by group FIELD
 well B-2H is controlled by group FIELD
 well B-1H is controlled by group FIELD
Production group B1 is NOT used by any well on the current processes 
Production group B1 is controlling 3 wells 
Production group C1 is NOT used by any well on the current processes 
Production group C1 is controlling 1 wells 
Production group F1 is NOT used by any well on the current processes 
Production group F1 is controlling 0 wells 
Production group FIELD is used by at least one well on the current processes 
Production group FIELD is controlling 4 wells 
Production group G1 is NOT used by any well on the current processes 
Production group G1 is controlling 0 wells 
Production group M5N is NOT used by any well on the current processes 
Production group M5N is controlling 1 wells 
Production group M5S is NOT used by any well on the current processes 
Production group M5S is controlling 3 wells 
Production group PLAT-A is NOT used by any well on the current processes 
Production group PLAT-A is controlling 4 wells 
Production group PROD is NOT used by any well on the current processes 
Production group PROD is controlling 0 wells 
Production group M5N has no constraints active, setting control mode to NONE

The lines with is controlling * wells is based on the number_of_wells_under_group_control. The lines with well on the current processes is output from this PR.

The group structure is like the following,

All the wells are basically controlled by FIELD, and there is no GCONPROD specified for F1, C1, PLAT-A. M5N has GCON specification, but it is not controlling any wells at this moment.

But we can see

Production group FIELD is controlling 4 wells 
Production group PLAT-A is controlling 4 wells 
Production group M5N is controlling 1 wells 
Production group C1 is controlling 1 wells 
Production group F1 is controlling 0 wells 
Production group M5S is controlling 3 wells
Production group B1 is controlling 3 wells  
Production group G1 is controlling 0 wells 

Basically, we should output NONE for groups PLAT-A, M5N, C1, F1, M5S, B1, G1.

It looks like there is a little bit different definition here.

number_of_wells_under_group_control means the wells under group control within this group, while this PR needs to know whether the group is providing active rate target to any wells.

[GitPaean]

jenkins build this failure_report please

[GitPaean]

We have the number_of_wells_under_group_control in groupstate. Couldn't that be used? If number_of_wells_under_group_control == 0 switch to NONE

It is possible. I was not aware of it and will evaluate it. From the code, the evaluation of that variable is relatively heavy. Will check whether it is totally equivalent to the approach here.

And furthermore, if I did not read the code wrong, we only care about whether groupControlledWells() is 0 or bigger than 0. There might be some room to simplify things.

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

jenkins build this failure_report please

[GitPaean]

The testing results are as expected and the description of the PR is updated.

It is ready for review from my side.

[GitPaean]

@totto82 , it will be very helpful if you can provide some comments regarding the last commit, which was introduced to fix the running test test_glift1. ff3eba3

[GitPaean]

jenkins build this failure_report please