OPM
Support defaulted item 3 for WCONPROD
Needed for a new field where client uses '' as value. We now assume that item 3 is defaulted in this case and if the star token is used. Default value used is NONE in these cases.
Please note the handling and detection of '' is handled in WellProductionProperties.cpp. The downside of this is that this means that the default handling is made at two places. The one for the star token is done directly in the parser automatically using the default specified in the json file of the keyword.
If we agree that '' (empty string) always marks a defaulted token for a string keyword then we should probably move all the detection to the star token code. But I am not knowledgeable enough to decide that. What does the commercial simulator do?
well it's running the case (ACTIONX_GCONPROD.DATA) so should be easily reproducable. i'll see if i can pinpoint the exact vector later today.
I have just built several test cases to see how this works and will post later today, as part of opm-tests.
Basically, 1* and '' behave the same, the good news. The bad news is the actual value used when WCONPROD(TARGET) is defaulted is dependent on the input. I need to run a couple more cases to finalize my findings.
On 01-Aug-22 15:12, Arne Morten Kvarving wrote:
well it's running the case (ACTIONX_GCONPROD.DATA) so should be easily reproducable. i'll see if i can pinpoint the exact vector later today.
— Reply to this email directly, view it on GitHub https://github.com/OPM/opm-common/pull/3088#issuecomment-1200805583, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJAQD4W35YCY4VFPPG7MS3VW52HLANCNFSM55A6BQUA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Evaluating category 'Group' (summary keyword GOPR) for FIELD', where I added
fmt::print("Evaluating category '{}' (summary keyword {}) for {}\n",
this->node_.category, this->node_.keyword, this->node_.wgname );
above the offending std::max(0, this->node_.number) call in Summary.cpp
Seems like jenkins is not happy as the iwell values are different now:
Keyword: IWEL, origin Restart, sequence 61
Value index = 7
(first value, second value) = (-1, -10)
....
Keyword: IWEL, origin Restart, sequence 61
Value index = 7
(first value, second value) = (-1, -10)
Non floating point values not identical
Keyword: IWEL, origin Restart, sequence 61
Value index = 162
(first value, second value) = (-1, -10)
Non floating point values not identical
Keyword: IWEL, origin Restart, sequence 61
Value index = 317
(first value, second value) = (-1, -10)
Value index = 7 Value index = 7 Value index = 162 Value index = 317 (first value, second value) = (-1, -10)
The IWEL array has 155 elements per well if there are no tracers. All of these elements therefore correspond to item 7 of the pertinent well. That, in turn, is the active well control. The values here are a bit concerning however. Negative one is GRUP control whereas -10 is an OPM extension representing an unknown control mode.
We probably need to look into that more closely before we decide what to do.
