OPM
Stop Processing if COPYing From Undefined Source Array
This PR adds defined value checking to the source array from which we're copying in a COPY operation–either with the COPY or with the COPYREG keywords. We count the number of source array values which do not have the status of deck_value and if this count is positive, then we throw an OpmInputError exception which halts further input processing.
As an example of this behaviour, the (deliberately faulty) setup
EQUALS
-- SGL not defined prior to this point
'SGL' 0.0 2* 2* 1 5 /
/
COPY
SGL SWL 2* 2* 4 7 /
/
will generate an "Error" of the form
Error: Problem with keyword COPY
In USER_ERR_COPY_BOX_PARTIALLY_UNDEF.DATA line 195
Copying from source array SGL in BOX (1-13, 1-22, 4-7)
would generate an undefined result in 572 blocks of target array SWL.
and stop input processing.
Similarly, For operations other than assignment (EQUALS keyword), this PR ensures that the array being mutated already exists in the input. In particular, this means that a request of the form
ADD
SGU 0.123 /
/
will halt input processing and generate an "Error" of the form
Error: Problem with keyword ADD
In USER_ERR_ADD.DATA line 202
Target array SGU must already exist when operated upon in ADD.
unless the SGU array has already been assigned earlier.
To this end, repurpose the second parameter to member function
FieldProps::try_get<>()
and make this a bitmask of flags instead of a single bool. The currently supported flags are AllowUnsupported and MustExist
with the former representing the original 'bool' parameter and the second requesting that the property array must already exist for the request to succeed.
Note: I am creating this PR in draft mode because it depends on, and contains, the earlier PR #4103. I will keep the PR in a draft state until it is ready for review and merging.
I have corrected the unexpected PORV related problem that presented the last time I updated this PR. I now consider this to be functionally complete and I'm marking it as "ready for review".
Two small suggestions that you may or may not take.
Thanks a lot for looking at this. I've pushed an update to address your comments. I'm always a little on the fence when it comes to switching on enums because while the set of valid enumerators is fixed, and typically small, the possible enumeration values are of course all of the values allowed by the underlying arithmetic type. That said, I replaced the if/else chain with a switch and a throw for unsupported enumeration values.
