jenkins build this please

jenkins build this please

When we declare a well-group to be a auto-choke manifold, we ignore all the group rate targets for all the wells in the group by

What is the expected behavoir when we use another line of WCONPROD

WCONPROD
--  Well_name  Status  Ctrl  Orate   Wrate  Grate Lrate   RFV  FBHP   WHP  VFP Glift
   'B-2H'      OPEN    GRUP  2500.0	 1*     1*    1*      1*   1*     1*   1   1*  /
/

to specify group control for this well?

When we declare a well-group to be a auto-choke manifold, we ignore all the group rate targets for all the wells in the group by

opm-common/opm/input/eclipse/Schedule/Network/NetworkKeywordHandlers.cpp

Line 199 in 66333cf

well.updateAvailableForGroupControl(false);

What is the expected behavoir when we use another line of WCONPROD

WCONPROD
--  Well_name  Status  Ctrl  Orate   Wrate  Grate Lrate   RFV  FBHP   WHP  VFP Glift
   'B-2H'      OPEN    GRUP  2500.0	 1*     1*    1*      1*   1*     1*   1   1*  /
/

to specify group control for this well?

I believe there should be no change (since the limits are what they were before), i.e., the group rate targets are still ignored. The problem is that current master crashes when encountering this, since the well is classified as not available for group control.

I believe there should be no change (since the limits are what they were before), i.e., the group rate targets are still ignored. The problem is that current master crashes when encountering this, since the well is classified as not available for group control.

Thanks for the response. I will test a little bit then get back to you.

Maybe as indicated by the testing in #4443 ,

we can just remove the if condition in the following code?

            if (well2.isAvailableForGroupControl()) {
                properties->addProductionControl(Well::ProducerCMode::GRUP);
            }

Maybe as indicated by the testing in #4443 ,

we can just remove the if condition in the following code?

            if (well2.isAvailableForGroupControl()) {
                properties->addProductionControl(Well::ProducerCMode::GRUP);
            }

And if we do this, potentially we have a few more of this checking can be removed. In the simulator code, we use isAvailableForGroupControl() to decide whether to handle group control, it looks like to me it can work by removing this condition check.

let us decide on this and more eyes are welcome here.

Maybe as indicated by the testing in #4443 ,
we can just remove the if condition in the following code?

            if (well2.isAvailableForGroupControl()) {
                properties->addProductionControl(Well::ProducerCMode::GRUP);
            }

And if we do this, potentially we have a few more of this checking can be removed. In the simulator code, we use isAvailableForGroupControl() to decide whether to handle group control, it looks like to me it can work by removing this condition check.

let us decide on this and more eyes are welcome here.

@totto82, could you have a look?

From my point of view the code changes looks good. @GitPaean I think we should keep the isAvailableForGroupControl() checks. You can still force the well to not be part of any group control using WGRUPCON item 2 = NO.

@GitPaean I think we should keep the isAvailableForGroupControl() checks. You can still force the well to not be part of any group control using WGRUPCON item 2 = NO.

Yes. I understand your point. The only situation that we have isAvailableForGroupControl() as false are either we have WGRUPCON item 2 = NO. or the well is in the auto-choke manifold.

And in the simulator code, we check isAvailableForGroupControl() whether to handle the well group control.

I do not see the difference whether to add control model GRUP in here. Especially for the situation the PR is handling now, even isAvailableForGroupControl() is false due to being part of the auto-choke manifold, we want to add GRUP control mode for this well to get the DATA file parsed. Later potentially we might have another case that comes with WGRUPCON item 2 = NO and we need to work around to to handle the WCONPROD with GRUP specification. Then we literally remove the if (well2.isAvailableForGroupControl()) checking by two working-rounds.

And for the vast majority of the wells, even we do not specify GRUP control for them and there is no group control in the case, they will have isAvailableForGroupControl() as true and add the GRUP control mode.

The reason that I prefer to remove the checking isAvailableForGroupControl(), is that it makes the situation simpler and when more functions/codes are added, they are more likely being challenged by future cases and potentially more work will be needed.

I do acknowledge the current PR fixes the running of the targeting case and have no intention to make it difficult. My only reservation is that I do not know how the group control and auto-choke manifold working together when the auto-choke manifold is higher in the group hierarchy, and that is also I think the function belongsToAutoChokeGroup() might be challenged in the future cases.

At the same time, since we begin introducing the exception such that a well can have isAvailableForGroupControl() as false and have GRUP control mode at the same time (although the GRUP control mode will not work), I am thinking that it can be easier by just removing the if (well2.isAvailableForGroupControl()) by all. #4443 testing shows it does not cause any regressions.

With said above, I will leave to @vkip to decide which approach to go. If you prefer the current approach, we can get ready to get the PR in. If you think removing the if condition is good while not having the capacity to handle the potential cleaning up of the logic, I can help to do it since it is something I prefer.

Just let me know.

I do acknowledge the current PR fixes the running of the targeting case and have no intention to make it difficult. My only reservation is that I do not know how the group control and auto-choke manifold working together when the auto-choke manifold is higher in the group hierarchy, and that is also I think the function belongsToAutoChokeGroup() might be challenged in the future cases.

At the same time, since we begin introducing the exception such that a well can have isAvailableForGroupControl() as false and have GRUP control mode at the same time (although the GRUP control mode will not work), I am thinking that it can be easier by just removing the if (well2.isAvailableForGroupControl()) by all. #4443 testing shows it does not cause any regressions.

With said above, I will leave to @vkip to decide which approach to go. If you prefer the current approach, we can get ready to get the PR in. If you think removing the if condition is good while not having the capacity to handle the potential cleaning up of the logic, I can help to do it since it is something I prefer.

Just let me know.

Well, the function belongsToAutoChokeGroup() simply checks if a well has an automatic choke somewhere up-tree, which in itself shouldn't be very problematic, but I agree that adding the GRUP control for a group with isAvailableForGroupControl() = false is not optimal. I think it would be better to avoid abusing the group control availability flag for the auto-choke functionality, which is a bit more work than this quick-fix, so great if you would like to help with that.

Once isAvailableForGroupControl() = true also for wells under auto-choke control (as they should be, since they are in fact group controlled, just in a different manner), I think the if statement can be left as it is in the current master. In principle this should facilitate taking wells out of group control using WGRUPCON. In reality this does not work though (see these test cases: wgrupcon_no_tests.tar.gz ), so we should probably also mark this feature as unsupported until actually implemented and tested..

I do acknowledge the current PR fixes the running of the targeting case and have no intention to make it difficult. My only reservation is that I do not know how the group control and auto-choke manifold working together when the auto-choke manifold is higher in the group hierarchy, and that is also I think the function belongsToAutoChokeGroup() might be challenged in the future cases.
At the same time, since we begin introducing the exception such that a well can have isAvailableForGroupControl() as false and have GRUP control mode at the same time (although the GRUP control mode will not work), I am thinking that it can be easier by just removing the if (well2.isAvailableForGroupControl()) by all. #4443 testing shows it does not cause any regressions.
With said above, I will leave to @vkip to decide which approach to go. If you prefer the current approach, we can get ready to get the PR in. If you think removing the if condition is good while not having the capacity to handle the potential cleaning up of the logic, I can help to do it since it is something I prefer.
Just let me know.

Well, the function belongsToAutoChokeGroup() simply checks if a well has an automatic choke somewhere up-tree, which in itself shouldn't be very problematic, but I agree that adding the GRUP control for a group with isAvailableForGroupControl() = false is not optimal. I think it would be better to avoid abusing the group control availability flag for the auto-choke functionality, which is a bit more work than this quick-fix, so great if you would like to help with that.

Once isAvailableForGroupControl() = true also for wells under auto-choke control (as they should be, since they are in fact group controlled, just in a different manner), I think the if statement can be left as it is in the current master. In principle this should facilitate taking wells out of group control using WGRUPCON. In reality this does not work though (see these test cases: wgrupcon_no_tests.tar.gz ), so we should probably also mark this feature as unsupported until actually implemented and tested..

Thanks for the response. When we talk about GRUP control, it is referring to GCONPROD and GCONINJE, both of which are rate controls. I do think it is okay to use isAvailableForGroupControl() = false for auto-choke manifold groups, since those groups do not handle the control from GCONPROD and GCONINJE anymore. That is why I suggested to just keep isAvailableForGroupControl() = false , while removing the requirement for avoid adding GRUP control when isAvailableForGroupControl() = false , that is what the targeting case https://github.com/user-attachments/files/18454068/NETWORK_MODEL5_STDW_AUTOCHK_V2.DATA.gz is doing. It is also part of what this PR is doing, while slightly broader scope. This PR is trying to add GRUP control for the auto-choke groups, while removing the if condition will add GRUP control for both auto-choke groups and WGRUPCON item 2 = NO situation.

Thanks for attaching wgrupcon_no_tests.tar.gz . Master branch does not run all of the cases. I understand the V2 and V3 cases, while I have not figured out what is wrong with the V1 case.

For V2 and V3, the problem is that WGRUPCON item 2 = NO is set after the GCON and WCON schedule keywords. If we want them to run, the master branch requires some fix, the master, this PR or my suggestion of removing if condition, they should not fix the running of the V2 and V3 cases. I do think it is a little different scenario that what this PR is trying to fix. or I misunderstood the cases.

I will try to get this PR in now to make things move forward to get the targeting case parsed and run. I will follow up a PR to remove the if condition checking. That PR is not targeting case, while remains a refactoring/simplification PR. The reviewing of the PR might not pass due to unforeseen scenarios.

jenkins build this please

Thanks for the update. I am getting the PR in now as promised.

Thanks for reviewing and merging! Just a couple of final clarifications:

Thanks for the response. When we talk about GRUP control, it is referring to GCONPROD and GCONINJE, both of which are rate controls. I do think it is okay to use isAvailableForGroupControl() = false for auto-choke manifold groups, since those groups do not handle the control from GCONPROD and GCONINJE anymore.

Maybe we just disagree on terminology. I would claim wells in auto-choke groups are available for group control since they are subject to group constraints set with GCONPROD, whereas wells taken out of group control with WGRUPCON item 2 = NO are not. Hence it would be less confusing (to me) if these two different concepts were represented with different flags.

For V2 and V3, the problem is that WGRUPCON item 2 = NO is set after the GCON and WCON schedule keywords. If we want them to run, the master branch requires some fix, the master, this PR or my suggestion of removing if condition, they should not fix the running of the V2 and V3 cases. I do think it is a little different scenario that what this PR is trying to fix. or I misunderstood the cases.

No, you're right - this is a different issue (but related).

I would claim wells in auto-choke groups are available for group control since they are subject to group constraints set with GCONPROD

I understand the terminology issue. But if we make isAvailableForGroupControl() = true for auto-choke groups , other group rate constraints based on guide rate will also be enforced unless we want to change how things work in a much bigger scope (codes or files will be touched).

To me it is easier to stick GRUP to the control from GCONPROD and GCONINJE.

I understand the terminology issue. But if we make isAvailableForGroupControl() = true for auto-choke groups , other group rate constraints based on guide rate will also be enforced unless we want to change how things work in a much bigger scope (codes or files will be touched).

Yes, changing this would require changes elsewhere also. I may come back to this later, but let's leave as it is for now.

just a note for later.

Whether a well get group controlled rate control is controlled by isAvailableForGroupControl(), that is why #4443 did not show any regression when we add GRUP control for all the wells. isAvailableForGroupControl() is also used actively in the simulator code to make sure we do not enforce GRUP control in the well control equations or the well control mode in the WellState.

The problem that this PR is trying to address is that we want to specify GRUP in the schedule with WCONPROD keywords. Even we specify the GRUP control in the WCONPROD, we will not be able to use GRUP control. (auto-choke manifold is enforced through THP constraints). Besides we add GRUP control even isAvailableForGroupControl() is false as suggested, another way to tackle this can be that we do not allow specify GRUP control if isAvailableForGroupControl() is false . For this situation, we can give a warning and specify BHP control as current control, which is always there. Because specifying GRUP for this situation will not work and will not be used in the simulator code.

Using GRUP in WCONPROD is and should be perfectly ok for wells belonging to auto-choke groups or network nodes. Automatic chokes are just a different way of enforcing group constraints, it is just in the current implementation this becomes problematic because of the re-use / abuse of existing code and concepts. I don't really have big problems with that and can see that it can make sense from an implementation point of view, but also suspect there may be issues if proper support of WGRUPCON item 2 = NO is to be implemented. We can cross that bridge when we get there.

I don't really have big problems with that and can see that it can make sense from an implementation point of view, but also suspect there may be issues if proper support of WGRUPCON item 2 = NO is to be implemented. We can cross that bridge when we get there.

Sure. It will be interesting to see how WGRUPCON item 2 = NO will affect the auto-choke manifold. My best guess it should not affect auto-choke manifold since there is no guide rates used in auto-choke manifold calculation.