Support WECON item 9 #4507

totto82 · 2025-03-06T07:51:09Z

No description provided.

totto82 · 2025-03-06T08:38:54Z

jenkins build this opm-simulators=6050 please

totto82 · 2025-08-26T09:17:59Z

jenkins build this opm-simulators=6050 please

GitPaean · 2025-08-26T14:15:04Z

opm/input/eclipse/Schedule/Well/WellTestState.hpp

    std::unordered_map<std::string, WTestWell> wells;
    std::unordered_map<std::string, std::unordered_map<int, ClosedCompletion>> completions;
-
+    std::vector<std::string> follow_on_wells;


I am not sure that I understand everything correct, so excuse me if I see things wrong.

I think with item 9 of WECON, we establish a relationship/mapping between one well A and another well B (which should be SHUT).

In case the well A is shut due to economic limits or physical limit, we open the well B.

But if we put them in a std::vector for all the wells, how do we manage the relationship between the well A -> well B?

Now I see that it is only added when the specific wells are shut. You can discard the above comment.

bska · 2025-08-27T07:10:29Z

I agree with @GitPaean. You need something stronger than a linear array to maintain the inter-well relationships implied by WECON(9).

Suppose we have

WECON
  'A' ... 'F1' /
  'B' ... 'F2' /
  'C' ... 'F3' /
/

If well C shuts in we're supposed to (try to) open well F3, not any one of the wells F1, F2, or F3.

bska

It's not obvious to me that this does what it claims to do. Please add a lot of unit tests and documentation here to justify the choice of data structures.

GitPaean · 2025-08-27T07:57:08Z

opm/input/eclipse/Schedule/Well/WellTestState.hpp

    std::unordered_map<std::string, WTestWell> wells;
    std::unordered_map<std::string, std::unordered_map<int, ClosedCompletion>> completions;
-
+    std::vector<std::string> follow_on_wells;


The follow-on well concept is input from the WECON keyword in the SCHEDULE, it is static. WellTestState is dynamic.

With the current implementation, this list is the wells that will be opened the next time step as a follow-on well.

Maybe something like pending_follow_on_wells or to_open_follow_on_wells will be more accurate or informational.

totto82 · 2025-08-27T08:08:18Z

I agree with @GitPaean. You need something stronger than a linear array to maintain the inter-well relationships implied by WECON(9).

Note that the inter-well relationship is taken care of by the simulator. This list gives all wells that the simulator opens at any point due to WECON.

totto82 · 2025-08-28T13:34:53Z

jenkins build this opm-simulators=6050 please

totto82 · 2025-08-28T13:37:46Z

I changed the implementation significantly and I am not yet finished so I will make it draft. Just want some help from Jenkins to sort out the missing parts.

totto82 · 2025-08-29T07:31:53Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-08-29T08:32:48Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-08-29T13:31:54Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-02T10:15:00Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-03T06:39:34Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-04T07:22:29Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-04T13:30:04Z

jenkins build this opm-simulators=6050 failure_report please

GitPaean

It looks generally fine. The following line probably can put inside a function to reduce duplication of the code and avoid inconsistency.

            if (handlerContext.getWellStatus(well_name) == WellStatus::OPEN) {
                handlerContext.state().wellgroup_events().addEvent( well_name, ScheduleEvents::REQUEST_OPEN_WELL);
                handlerContext.state().wellgroup_events().clearEvent( well_name, ScheduleEvents::REQUEST_SHUT_WELL);
            }
            if (handlerContext.getWellStatus(well_name) == WellStatus::SHUT) {
                handlerContext.state().wellgroup_events().addEvent( well_name, ScheduleEvents::REQUEST_SHUT_WELL);
                handlerContext.state().wellgroup_events().clearEvent( well_name, ScheduleEvents::REQUEST_OPEN_WELL);
            }

And furthermore, to qualify as a follow on well, the well needs to be a valid SHUT well when parsing, the master branch does not deal with that yet.

GitPaean · 2025-09-05T11:57:19Z

opm/input/eclipse/Schedule/Well/WellKeywordHandlers.cpp

            }
+            if (handlerContext.state().wells.get( well_name ).getStatus() == Well::Status::SHUT) {
+                handlerContext.state().wellgroup_events().addEvent(well_name, ScheduleEvents::REQUEST_SHUT_WELL);
+            }


Why is this one different from the other occasions without clearing?

totto82 · 2025-09-08T07:38:25Z

jenkins build this opm-simulators=6050 please

totto82 · 2025-09-08T07:45:45Z

And furthermore, to qualify as a follow on well, the well needs to be a valid SHUT well when parsing, the master branch does not deal with that yet.

I guess checking this on the parser level is less trivial than checking it on the simulator level when it is activated. Is this an abort simulation condition or just a warning?

GitPaean · 2025-09-08T08:21:03Z

Is this an abort simulation condition or just a warning?

I think we can treat it as a warning and disqualify the follow on well.

I guess checking this on the parser level is less trivial than checking it on the simulator level when it is activated.

It is fair to say that. If we want to do at the parsing stage, the well needs to be valid and is SHUT in the schedule when parsing WECON.

And checking at the simulator stage probably allowing more flexibility.

totto82 · 2025-09-08T08:28:48Z

And checking at the simulator stage probably allowing more flexibility.
Done.

Thanks for the review!

totto82 · 2025-09-08T09:47:42Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-08T10:52:50Z

jenkins build this opm-simulators=6050 failure_report please

GitPaean

Thanks for the update. It looks good to me.

totto82 · 2025-09-10T13:41:18Z

jenkins build this opm-simulators=6050 please

totto82 · 2025-09-10T14:13:58Z

jenkins build this opm-simulators=6050 failure_report please

totto82 · 2025-09-12T07:50:27Z

jenkins build this opm-simulators=6050 failure_report please

GitPaean · 2025-09-12T09:32:00Z

jenkins build this opm-simulators=6050 update_data please

GitPaean · 2025-09-12T09:46:50Z

jenkins build this opm-simulators=6050 update_data please

PR OPM/opm-simulators#6050 Reason: PR OPM/opm-common#4507 PR OPM/opm-simulators#6050 opm-common = c62ecb474d75a3453f48521e0d5a4a5d6b699e50 opm-grid = 3106eb85512718be5c5541ee8fd37b2372abe93a opm-simulators = c62ecb474d75a3453f48521e0d5a4a5d6b699e50 ### Changed Tests ### * 3dwecon9

GitPaean · 2025-09-12T11:27:29Z

jenkins build this opm-simulators=6050 opm-tests=1393 please

totto82 · 2025-09-16T07:41:48Z

@GitPaean Any reasons for not merging this?

totto82 · 2025-09-16T11:12:30Z

jenkins build this opm-simulators=6050 opm-tests=1393 please

GitPaean · 2025-09-16T11:13:38Z

jenkins build this opm-simulators=6050 update_data please

PR OPM/opm-simulators#6050 Reason: PR OPM/opm-common#4507 PR OPM/opm-simulators#6050 opm-common = 49104d7e0e492d4980243d6def64c35939626a59 opm-grid = 3106eb85512718be5c5541ee8fd37b2372abe93a opm-simulators = 49104d7e0e492d4980243d6def64c35939626a59 ### Changed Tests ### * 3dwecon9

GitPaean · 2025-09-16T12:28:32Z

jenkins build this opm-simulators=6050 opm-tests=1399 please

…simulators_6050 Automatic Reference Data Update for PR OPM/opm-common#4507

totto82 mentioned this pull request Mar 6, 2025

Support opening of following-on well OPM/opm-simulators#6050

Merged

GitPaean self-requested a review June 18, 2025 13:06

totto82 added the manual:enhancement This is an enhancement/improvent that needs to be documented in the manual label Aug 26, 2025

GitPaean reviewed Aug 26, 2025

View reviewed changes

bska requested changes Aug 27, 2025

View reviewed changes

GitPaean reviewed Aug 27, 2025

View reviewed changes

totto82 force-pushed the wecon9 branch from 8cc1a63 to 3cc0d6c Compare August 28, 2025 13:34

totto82 marked this pull request as draft August 28, 2025 13:35

totto82 force-pushed the wecon9 branch from 3cc0d6c to 011b151 Compare August 29, 2025 07:30

totto82 force-pushed the wecon9 branch from 011b151 to 3cc6cbc Compare August 29, 2025 08:31

totto82 marked this pull request as ready for review September 4, 2025 13:58

GitPaean requested changes Sep 5, 2025

View reviewed changes

totto82 force-pushed the wecon9 branch from 3cc6cbc to 6ad7d96 Compare September 8, 2025 07:36

Support WECON item 9

00d28dd

totto82 force-pushed the wecon9 branch from 6ad7d96 to 00d28dd Compare September 8, 2025 10:52

GitPaean approved these changes Sep 10, 2025

View reviewed changes

jenkins4opm mentioned this pull request Sep 12, 2025

Automatic Reference Data Update for PR https://github.com/OPM/opm-common/pull/4507 OPM/opm-tests#1393

Closed

jenkins4opm mentioned this pull request Sep 16, 2025

Automatic Reference Data Update for PR https://github.com/OPM/opm-common/pull/4507 OPM/opm-tests#1399

Merged

GitPaean added a commit to OPM/opm-tests that referenced this pull request Sep 16, 2025

Merge pull request #1399 from jenkins4opm/update_opm-common_4507_opm-…

7e9a9fe

…simulators_6050 Automatic Reference Data Update for PR OPM/opm-common#4507

GitPaean merged commit a4d6a93 into OPM:master Sep 16, 2025
2 checks passed

Support WECON item 9 #4507

Support WECON item 9 #4507

Conversation

totto82 commented Mar 6, 2025

Uh oh!

totto82 commented Mar 6, 2025

Uh oh!

totto82 commented Aug 26, 2025

Uh oh!

GitPaean Aug 26, 2025

Choose a reason for hiding this comment

Uh oh!

GitPaean Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

bska commented Aug 27, 2025

Uh oh!

bska left a comment

Choose a reason for hiding this comment

Uh oh!

GitPaean Aug 27, 2025

Choose a reason for hiding this comment

Uh oh!

totto82 commented Aug 27, 2025

Uh oh!

totto82 commented Aug 28, 2025

Uh oh!

totto82 commented Aug 28, 2025

Uh oh!

totto82 commented Aug 29, 2025

Uh oh!

totto82 commented Aug 29, 2025

Uh oh!

totto82 commented Aug 29, 2025

Uh oh!

totto82 commented Sep 2, 2025

Uh oh!

totto82 commented Sep 3, 2025

Uh oh!

totto82 commented Sep 4, 2025

Uh oh!

totto82 commented Sep 4, 2025

Uh oh!

GitPaean left a comment

Choose a reason for hiding this comment

Uh oh!

GitPaean Sep 5, 2025

Choose a reason for hiding this comment

Uh oh!

totto82 commented Sep 8, 2025

Uh oh!

totto82 commented Sep 8, 2025

Uh oh!

GitPaean commented Sep 8, 2025

Uh oh!

totto82 commented Sep 8, 2025

Uh oh!

totto82 commented Sep 8, 2025

Uh oh!

totto82 commented Sep 8, 2025

Uh oh!

GitPaean left a comment

Choose a reason for hiding this comment

Uh oh!

totto82 commented Sep 10, 2025

Uh oh!

totto82 commented Sep 10, 2025

Uh oh!

totto82 commented Sep 12, 2025

Uh oh!

GitPaean commented Sep 12, 2025

Uh oh!

GitPaean commented Sep 12, 2025

Uh oh!

GitPaean commented Sep 12, 2025

Uh oh!

totto82 commented Sep 16, 2025

Uh oh!

totto82 commented Sep 16, 2025

Uh oh!