Network well without vfp - #7333
Open
GitPaean wants to merge 9 commits into
Open
Conversation
GitPaean
added
the
manual:irrelevant
GitPaean
force-pushed
the
network-well-without-vfp
branch
2 times, most recently
from
August 20, 2026 09:11
ce1e43e to
a127162
Compare
GitPaean
force-pushed
the
network-well-without-vfp
branch
2 times, most recently
from
August 25, 2026 17:22
0aa7012 to
bc84522
Compare
Contributor
|
This PR has now been tested in Equinor and results are good. Looking forward to see this go into master. |
Member
|
I'll review this, but the PR has merge conflicts that must be resolved before it's ready for merging. Please rebase this work onto the current master sources. |
Member
Author
Thanks. The development has been some while, please allow some minutes to let me go through it again and will note when I am done. |
GitPaean
force-pushed
the
network-well-without-vfp
branch
from
August 27, 2026 09:31
bf37256 to
9121475
Compare
GitPaean
marked this pull request as draft
August 27, 2026 09:36
GitPaean
force-pushed
the
network-well-without-vfp
branch
from
August 27, 2026 12:04
6111c39 to
47c760f
Compare
Copilot stopped reviewing on behalf of
GitPaean due to an error
August 27, 2026 12:20
GitPaean
force-pushed
the
network-well-without-vfp
branch
2 times, most recently
from
August 28, 2026 08:31
5556b9f to
dac8482
Compare
GitPaean
force-pushed
the
network-well-without-vfp
branch
from
August 28, 2026 10:03
dac8482 to
ee943f5
Compare
Without a VFP table a THP limit cannot be converted to a BHP, so the well cannot operate under a THP constraint. Previously, a network well with WCONPROD items 10 and 11 defaulted aborted the simulation with "Nonexistent VFP table 0 referenced". The well now stays on its remaining controls while its rates still enter the network pressure calculation.
activeProductionConstraint() skipped the switch to THP control for GRUP-controlled wells when ws.trivial_group_target was set. That flag is only rewritten in updateWellStateWithTarget() when a well switches control, so it can go stale - it is set at the initial ORAT->GRUP switch while a sibling well still covers the whole group target - and the veto then blocks the very switch that would refresh it. Network wells could therefore keep flowing with a THP below the nodal pressure of the node they feed, which Eclipse never does. Both call paths into checkIndividualConstraints() already return early for wells whose freshly evaluated group target is zero (stoppedOrZeroRateTarget() and wellUnderZeroRateTarget()), so the veto could only ever act on stale information and is removed.
The preceding commit removed the only reader of this flag, leaving write-only state that was still computed, serialized and compared. Wells with a trivial group rate target are recognised on demand by stoppedOrZeroRateTarget() and wellUnderZeroRateTarget(). The else branch of the rate scaling only existed to set the flag and goes with it; the scaling itself is unchanged.
The limit is stored in SingleWellState and stays in force, also across shut periods, until the deck re-specifies the well THP limit or VFP table (the WELL_THP_UPDATE event of the companion opm-common branch). Previously a detached well silently reverted to the static THP limit from the deck.
Report-step events do not reach the simulator for ACTIONX updates, so the SimulatorUpdate::thp_respecified_wells set of the companion opm-common branch is used instead.
No restart array carries the retained limit yet, so it is reconstructed for a detached THP-controlled producer whose restart THP differs from the schedule THP limit (a well on its own, possibly UDA-driven, limit is left untouched). A retained limit that is not active at the restart time is lost; this limitation is documented in the code.
The network cannot put a well without a VFP table under THP control, so it should neither impose a dynamic THP limit on such a well nor record a retained network_thp_limit for it. Previously only wellHasTHPConstraints() neutralized the imposed limit; guarding the imposition sites as well keeps the retained state meaningful and removes the reliance on every getTHPConstraint() caller checking wellHasTHPConstraints() first. No result changes: the guarded paths were inert for wells without a VFP table.
The auto-choke group pressure is imposed on its wells through a path of its own. Apply the same eligibility rule as for the extended network: a well without a VFP table cannot be put under THP control, so no THP limit is imposed on it, while its rates still contribute to the group flow. No result changes: wellHasTHPConstraints() already neutralized the imposed limit for such wells, so the guarded path was inert.
Pressures left from an earlier network were imposed on the wells as if they had just been balanced.
GitPaean
force-pushed
the
network-well-without-vfp
branch
from
August 28, 2026 12:41
ee943f5 to
58af0b0
Compare
GitPaean
marked this pull request as ready for review
August 28, 2026 12:45
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A well can be attached to a production network without a VFP curve specified for it. OPM Flow aborts the run with Nonexistent VFP table 0 referenced, which is not a helpful message. This PR makes that case run, and fixes a second problem for wells attached to a network.
A well whose THP limit and VFP table are defaulted (WCONPROD items 10 and 11) is no longer treated as THP-constrained when the network imposes a limit on it, so it stays on its remaining controls while its rates still enter the network pressure calculation. A THP limit entered in the deck is left alone, so a missing VFP table is still reported there. The same eligibility rule is applied wherever a network THP limit is imposed or retained: the extended network, auto-choke groups, and the reconstruction at restart.
A well that leaves the network — for instance moved to a non-network group by WELSPECS — now keeps the THP limit last imposed by network balancing until the schedule re-specifies its THP limit or VFP table, instead of silently reverting to the static limit from the deck. The limit is stored in SingleWellState, so it also survives shut periods and is reconstructed at restart. Node pressures left over from an earlier network are dropped at the start of a report step, so they are not imposed as if they had just been balanced. A unit test covers the retention and its cancellation.
Also removes the trivial_group_target veto in activeProductionConstraint(), which skipped the switch to THP control for GRUP-controlled wells. The flag is only rewritten when a well switches control, so it could go stale and block the very switch that would refresh it, letting network wells produce with a THP below the pressure of the node they feed. Both call paths already return early for wells whose freshly evaluated group target is zero, so the veto could only act on stale information; the flag itself is now unused and removed.
Depends on OPM/opm-common#5298 (WELL_THP_UPDATE event and SimulatorUpdate::thp_respecified_wells), which is what detects re-specification even when the entered values are unchanged.