Allow change of target constraint

[plgbrts]

This PR enhances current functionality for the situation of having autochoke groups in the network. Besides a rate target additional rate constraints may be specified for a parent group in GCONPROD. For example

GCONPROD    
‘AB’         'ORAT'   10000.0   5500.0   1*    10000.0   'RATE'  'YES'   10000.0  'LIQ'    'RATE'   'RATE'   'RATE'   3* /    
‘A’          'FLD'    1*        1*       1*    1*        'RATE'  'YES'   5000.0   'LIQ'    'RATE'   'RATE'   'RATE'   3* 
‘B’          'FLD'    1*        1*       1*    1*        'RATE'  'YES'   5000.0   'LIQ'    'RATE'   'RATE'   'RATE'   3* 

Here parent group AB has an oil rate target of 10000 m3/day and a water rate constraint of 5500 m3/day. The children groups may be auto choke groups. If the water rate constraint gets broken it becomes the target.
This behavior has been tested on a field case.

The PR depends on the upstream PR OPM/opm-common#4622 .

[plgbrts]

jenkins build this opm-common=4622 please

[GitPaean]

This PR enhances current functionality for the situation of having autochoke groups in the network. Besides a rate target additional rate constraints may be specified for a parent group in GCONPROD. For example

GCONPROD    
‘AB’         'ORAT'   10000.0   5500.0   1*    10000.0   'RATE'  'YES'   10000.0  'LIQ'    'RATE'   'RATE'   'RATE'   3* /    
‘A’          'FLD'    1*        1*       1*    1*        'RATE'  'YES'   5000.0   'LIQ'    'RATE'   'RATE'   'RATE'   3* 
‘B’          'FLD'    1*        1*       1*    1*        'RATE'  'YES'   5000.0   'LIQ'    'RATE'   'RATE'   'RATE'   3* 

Here parent group AB has an oil rate target of 10000 m3/day and a water rate constraint of 5500 m3/day. The children groups may be auto choke groups. If the water rate constraint gets broken it becomes the target. This behavior has been tested on a field case.

The PR depends on the upstream PR OPM/opm-common#4622 .

Thanks for the contribution.

Can you share the complete the setup of the case so we can understand the exact situation the PR is trying to solve?

Furthermore, it is probably a good idea to have a regression test since this is a new feature/new scenario can OPM-flow can handle. Regression test can prevent the development from getting broken by others.

[GitPaean]

const bool here. And also, it is good to define the variable as close as possible to the actual usage. Since the usage is within a for loop, you can define it right before the for loop that actually use the variable to avoid repeated evaluation.

[GitPaean]

same comment as previous comment.

[plgbrts]

Can you share the complete the setup of the case so we can understand the exact situation the PR is trying to solve?

Furthermore, it is probably a good idea to have a regression test since this is a new feature/new scenario can OPM-flow can handle. Regression test can prevent the development from getting broken by others.

Good points. I created a small test case:
GROUPGUIDERATES_AC_CONSTRAINT.zip
I will create a regression test based on this example.

In the example case the parent group M5S has two child groups B1 and C1 both with wells. B1 is an auto choke group. M5S has an ORAT target of 8000 m3/day and a WRAT constraint of 800 m3/day. In the figure below it can be seen that initially M5S satisfies the ORAT target and after some time the WRAT constraint becomes the target and M5S obeys it.

[GitPaean]

Can you share the complete the setup of the case so we can understand the exact situation the PR is trying to solve?
Furthermore, it is probably a good idea to have a regression test since this is a new feature/new scenario can OPM-flow can handle. Regression test can prevent the development from getting broken by others.

Good points. I created a small test case: GROUPGUIDERATES_AC_CONSTRAINT.zip I will create a regression test based on this example.

In the example case the parent group M5S has two child groups B1 and C1 both with wells. B1 is an auto choke group. M5S has an ORAT target of 8000 m3/day and a WRAT constraint of 800 m3/day. In the figure below it can be seen that initially M5S satisfies the ORAT target and after some time the WRAT constraint becomes the target and M5S obeys it.

Hei, @plgbrts , thanks for the sharing the case.

Testing with the case it looks like

    bool has_choke = schedule.hasChoke(group.name(), reportStepIdx);

is working the same with group.as_choke(). Maybe it works differently with other cases. At least with the case you provided, they work the same. If it is not the case, please let me know.

Furthermore, during testing, it looks like the master branch produces the same results with this PR. Is it something that you have understanding with it?

And also, testing shows that the first if condition if (!has_choke){ does not affect the cases with auto-chokes, which is also a surprise. From the code, it looks like it should be there.

The above is some observation from my side for your information. Please let me know if you saw things differently and I can re-test it.

[GitPaean]

jenkins build this opm-common=4622 failure_report please