Give meaningful error for out-of-range well perforations in ACTIONX. #4336
Conversation
"Input index above valid range" might not ring any bells. Now we include information about the index and the expected range.
Previously we threw an exception that was poorly handled by the loggin system. The user e.g. saw: ``` Reading from: BLA.INC line 2 Error: An error occurred while creating the reservoir schedule Internal error: input IJK index above valid range Error: Unrecoverable errors while loading input: input IJK index above valid range ``` With this commit we use the ParseContext to give a more meaningful error message like: ``` Error: Problem with COMPDAT in ACTIONX In BLA.INC line 19 Cell (83, 273, 47) of well EX_WA is not part of the grid (Input IJK index (83, 273, 47) not part of grid with dimensions 169x359x46.). Error: Problem with keyword COMPDAT In BLA.INC line 19 Problem with COMPDAT in ACTIONX In BLA.INC line 19 Cell (83, 273, 47) of well EX_WA is not part of the grid (Input IJK index (83, 273, 47) not part of grid with dimensions 169x359x46.). Error: Unrecoverable errors while loading input: Problem with keyword COMPDAT In BLA.INC line 19 Problem with COMPDAT in ACTIONX In BLA.INC line 19 Cell (83, 273, 47) of well EX_WA is not part of the grid (Input IJK index (83, 273, 47) not part of grid with dimensions 169x359x46.). ```
|
jenkins build this please |
|
Note that we might not give such nice error outside of ACTIONX for well stuff... |
There was a problem hiding this comment.
On the one hand, it's always good to give better diagnostics. On the other hand, we arguably should never throw from a function that explores the possible future connections without knowing if these connections materialise. At least I'd prefer if we made the action be InputErrorAction::WARN instead of throwing an exception in the context of prefetching potential future connections.
|
I think this something that the current users should decide. The decision is basically between whether we should fail fast because a keyword does obviously not make sense as is or risk to run a simulation for hours in the hope that in ACTION never becomes executed to then realize the next morning the simulation was aborted.... If course we can warn and ignore these problems in the running simulation. Anyway, I also want to check how the simulator behaves for such problems outside of ACTIONX. Marking this as WIP, therefore. |
Yeah...I'm conflicted. If the parsing mode is strict I want to know about these things, but for "normal" I think I'd prefer a warning and that connections outside the model just be ignored. For "low" such connections might just be silently ignored altogether. |
|
BTW We also have problematic behavior if such problems appear outside ACTIONX (modifying SPE1CASE2) parsing aborts prematurely with Note that the error message is at least improved with this PR (previously: "Internal error: input IJK index above valid range"). |
And that's arguably a bug in |
|
I am undrafting this as it is a real improvement to the current situations for usersand does not change the behavior of the simulator. Therefore this should be merged. |
Okay, fair enough.
Cool. I'll merge into master. |
|
Thanks. Highly appreciated. |
About this, the consensus seems to me that we should fail fast here. Is that what we are doing now, or are more changes required for that? |
|
We are currently failing as soon as possible, i.e. when parsing the SCHEDULE for the very first time. |
Previously we threw an exception that was poorly handled by the logging system. The user e.g. saw:
With this commit we use the ParseContext to give a more meaningful error message like: