Support WCONHIST/WCONINJ in ACTIONX #4527
Conversation
|
jenkins build this opm-simulators=6092 please |
| @@ -171,6 +171,7 @@ void handleWCONHIST(HandlerContext& handlerContext) | |||
| handlerContext.state().wellgroup_events().addEvent( well_name, ScheduleEvents::REQUEST_OPEN_WELL); | |||
| } | |||
|
|
|||
| handlerContext.affected_well(well_name); | |||
There was a problem hiding this comment.
Very strictly speaking this statement should probably be moved up a bit, into the update_well block. If you put it here the simulation layer will be forced to reset the well controls even if the controls don't actually change (rare case).
There was a problem hiding this comment.
I am rather skeptical about this. The history and bhp limit seems to be set in WellKeywordHandlers.cpp#L134, but update_well stays fasle. It is unclear to me whether true is implied from somewhere else.
There was a problem hiding this comment.
The history and bhp limit seems to be set in WellKeywordHandlers.cpp#L134, but update_well stays fasle.
The WellProductionProperties::handleWCONHIST() call on line 134 changes an independent object created on line 103. Whether or not that has any effect at all on the well itself is determined in the Well::updateProduction() call on line 151. If it does, then update_well gets set to true.
| @@ -328,6 +329,7 @@ void handleWCONINJH(HandlerContext& handlerContext) | |||
| handlerContext.state().wellgroup_events().addEvent( well_name, ScheduleEvents::REQUEST_OPEN_WELL); | |||
| } | |||
|
|
|||
| handlerContext.affected_well(well_name); | |||
There was a problem hiding this comment.
This should probably be in the update_well block.
|
I'll test the update_well approach, too. I did not go done that route intentionally, but let's see. But I need to do other stuff first and this will be hanging for a few days... |
This is now battle tested by the client.