Rework initialization of segment pressures #6587

steink · 2025-11-03T10:11:39Z

Current initialization of segment pressures can be problematic for two reasons:

If a well is initialized with bhp-control, then all segments that don't have perforations will be initialized to that bhp-value, while segments with perforations will be initialized to the perforation pressures. This will typically result in a large jump between perforation/non-perforation segments, which can be problematic as initial guess for the solving.
Wells can get initialized in a shut-state meaning that ws.bhp is zero. If such a well subsequently opens, it will copy the segment pressures for the shut-state initialization, i.e., it gets zero pressure for all segments that does not have perforations. This situation leads to the well failing to produce non-zero rates in computeWellRatesWithBhp (for any bhp > 0) as used in e.g., initializeProducerWellState. Hence , such a well will fail to obtain explicit rates as needed in e.g., operability checks (in addition it's a difficult initial guess for the well solve).

This PR simply sugests to use perforation pressures to initialize all segment pressures (and disregard the previously set ws.bhp). In this way, in subsequent call to scaleSegmentPressuresWithBhp , all segment pressures will be approximately at level without large jumps, and computeWellRatesWithBhp will not fail to produce non-zero rates (unless it should due to low reservoir pressure).

steink · 2025-11-03T10:12:26Z

jenkins build this failure_report please

steink · 2025-11-03T10:43:49Z

opm/simulators/wells/WellState.cpp

            auto& new_well = this->well(w);
            new_well.init_timestep(prev_well);

            if (prev_well.status == Well::Status::SHUT) {


After discussion with @GitPaean, it appears that this does not trigger (since the well is not supposed to copy the shut-well state)

The change in this PR is going through a different path.

Opm::WellState::initWellStateMSWell WellState.cpp:692 Opm::BlackoilWellModel::initializeLocalWellStructure BlackoilWellModel_impl.hpp:269 Opm::BlackoilWellModel::beginReportStep BlackoilWellModel_impl.hpp:208 Opm::SimulatorFullyImplicitBlackoil::runStep SimulatorFullyImplicitBlackoil.hpp:389 Opm::SimulatorFullyImplicitBlackoil::run SimulatorFullyImplicitBlackoil.hpp:187 Opm::FlowMain::runSimulatorRunCallback_ FlowMain.hpp:377 Opm::FlowMain::runSimulatorInitOrRun_ FlowMain.hpp:461 Opm::FlowMain::runSimulator FlowMain.hpp:364 Opm::FlowMain::execute_ FlowMain.hpp:257 Opm::FlowMain::execute FlowMain.hpp:176 Opm::flowMain<…> Main.hpp:92 Opm::Main::dispatchStatic_<…> Main.hpp:381 Opm::Main::runStatic<…> Main.hpp:158 Opm::flowBlackoilTpfaMainStandalone flow_blackoil.cpp:77 main flow_blackoil_main.cpp:24 __libc_start_call_main 0x00007ffff742a1ca __libc_start_main_impl 0x00007ffff742a28b _start 0x00005555556a9065

if (this->param_.use_multisegment_well_ && this->anyMSWellOpenLocal()) { this->wellState().initWellStateMSWell(this->wells_ecl_, &this->prevWellState()); }

But in the function this->wellState().initWellStateMSWell() it does not copy results from SHUT well either.

Yes, this is true. I'll need some more debugging to figure why an opened well can get initialized with zero bhp. The PR prevents this problem, but still it's likely a bug so worth figuring out.

Did some more digging into this. Seems the issue is related to wells that get opened by an action. For the case I'm looking at, some shut wells get a WELOPEN (through pyaction). When next time-step begins, they go through initWellStateMSWell, but in contrast to wells that open normally, their segment rates/pressures are reset to previous state since prev_ws.status == Well::Status::SHUT returns false for these wells.

I don't really know the action-part of the code well, but could the reason for the failed logic above be the this->wellModel_.commitWGState() in applyActions?

We get around the above problem with this PR (will update), but could there be other parts of the code which relies on the same logic?

GitPaean · 2025-11-03T13:06:49Z

I have not looked at the code. Most of the regression failures are okay, while not sure what is the following failure about.

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

is the following the reason that the test failed?

Warning: GPU expression did not execute correctly. Expression was: 
    cudaGetDeviceCount(&deviceCount)
GPU error was CUDA driver version is insufficient for CUDA runtime version
in function printDevice, in /var/lib/jenkins/post-builder/workspace/opm-simulators-PR-builder/opm/simulators/linalg/gpuistl/device_management.cpp, at line 52

GitPaean

I understand the idea here, to have the segment pressure around the reservoir level so they can also produce, while totally sure how it should be done.

leaving some comments on the code level for now. more thinking are needed for the review.

GitPaean · 2025-11-03T14:52:44Z

opm/simulators/wells/WellState.cpp

+                // pressures equal to the closest set pressure in the outlet direction.
+                if (std::any_of(segment_pressures.begin(), segment_pressures.end(),
+                             [](const Scalar p){ return p < 0.0; })) {
+                    setSegmentPressuresFromOutlets(segment_pressures, segment_inlets, 0 /* segment */, -1 /* outlet segment */);


to make this code work segment_pressures[0] can not be negative. an safety checking will be needed here.

Yes, if top segment pressure us unset at this stage, it means the well has no connections which I guess should not happen at this stage, but better to be safe. In this situation arises, I guess it's best just to set it to bhp (which means all segments will get that pressure).

or more directly, inside the function setSegmentPressuresFromOutlets(), make sure the -1 index should not be used.

GitPaean · 2025-11-03T14:57:33Z

opm/simulators/wells/WellState.hpp

                                      const int                            segment,
                                      std::vector<Scalar>&                 segment_rates);

+    void setSegmentPressuresFromInlets(std::vector<Scalar>& segment_pressures,


These two functions have to be called together. Calling either one only is not a complete process.

They should be made private, and called through another function (can also be private unless needs to be public) including these two function calls.

I will set them private. I'm not 100% sure the second one is needed (that is, if a well is allowed to have toe-segemnts without perforations), but included it just in case.

GitPaean · 2025-11-03T15:22:12Z

I have not looked at the code. Most of the regression failures are okay, while not sure what is the following failure about.

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

is the following the reason that the test failed?
Warning: GPU expression did not execute correctly. Expression was: 
    cudaGetDeviceCount(&deviceCount)
GPU error was CUDA driver version is insufficient for CUDA runtime version
in function printDevice, in /var/lib/jenkins/post-builder/workspace/opm-simulators-PR-builder/opm/simulators/linalg/gpuistl/device_management.cpp, at line 52

The local running with the PR is fine. Not totally sure what happens with Jenkins here. We will see from next jenkins test.

GitPaean · 2025-11-03T17:01:03Z

jenkins build this failure_report please

GitPaean · 2025-11-04T09:18:45Z

I have not looked at the code. Most of the regression failures are okay, while not sure what is the following failure about.
https://ci.opm-project.org/job/opm-simulators-PR-builder/8962/testReport/junit/(root)/mpi/NORNE_RESTART/
is the following the reason that the test failed?
Warning: GPU expression did not execute correctly. Expression was: 
    cudaGetDeviceCount(&deviceCount)
GPU error was CUDA driver version is insufficient for CUDA runtime version
in function printDevice, in /var/lib/jenkins/post-builder/workspace/opm-simulators-PR-builder/opm/simulators/linalg/gpuistl/device_management.cpp, at line 52
The local running with the PR is fine. Not totally sure what happens with Jenkins here. We will see from next jenkins test.

The failure was gone in the new jenkins result.

…sures

steink · 2025-11-06T12:56:02Z

jenkins build this failure_report please

Rework initialization of segment pressures

ed4e182

steink added the manual:irrelevant This PR is a minor fix and should not appear in the manual label Nov 3, 2025

steink commented Nov 3, 2025

View reviewed changes

steink requested a review from GitPaean November 3, 2025 10:44

GitPaean reviewed Nov 3, 2025

View reviewed changes

steink added 2 commits November 6, 2025 13:53

Updates according to PR comments

cd5a082

Merge branch 'OPM:master' into Rework-initialization-of-segement-pres…

91650e6

…sures

steink mentioned this pull request Nov 11, 2025

investigate potentially problematic updating of well status from action handler #6602

Draft

Rework initialization of segment pressures #6587

Are you sure you want to change the base?

Rework initialization of segment pressures #6587

Uh oh!

Conversation

steink commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steink commented Nov 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitPaean commented Nov 3, 2025

Uh oh!

GitPaean left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GitPaean commented Nov 3, 2025

Uh oh!

GitPaean commented Nov 3, 2025

Uh oh!

GitPaean commented Nov 4, 2025

Uh oh!

steink commented Nov 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

steink commented Nov 3, 2025 •

edited

Loading

GitPaean left a comment •

edited

Loading