Network well without vfp - #7333
Open
GitPaean wants to merge 7 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
from
August 21, 2026 09:45
a127162 to
0aa7012
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_respec_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.
GitPaean
force-pushed
the
network-well-without-vfp
branch
from
August 25, 2026 17:22
0aa7012 to
bc84522
Compare
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.
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
1 participant
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.
Fixes two problems for wells attached to a production network. A well whose THP limit and VFP table are defaulted (WCONPROD items 10 and 11) is no longer treated as THP-constrained, so it stays on its remaining controls instead of aborting the run with Nonexistent VFP table 0 referenced while its rates still enter the network pressure calculation. 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.
Also refreshes trivial_group_target when the well group target is recomputed: a value latched at a transient zero share previously suppressed THP constraint checks for the rest of the report step, letting network wells produce with their THP below the node pressure.
Depends on OPM/opm-common#5298 (WELL_THP_UPDATE event and SimulatorUpdate::thp_respec_wells), which is what detects re-specification even when the entered values are unchanged.