2020-10 Brine Test Throws an Exception

[OPMUSER]

This worked in 2020-04 but throws

Program threw an exception: Could not initialize the problem: Tried to evaluate a tabulated function outside of its range

Decks attached.
SPE01-BRINE01.zip

[joakim-hove]

I can confirm the error message in my master. It is not clear to me what the error is - might be trivial, might be a bit more work. I would not hold back the release for this.

[bska]

I see this in the release build on my local machine. The immediate cause is that the SALTVD table covers the range of 5000 to 5500 ft, but that the top of the formation is at 8325 ft and the SALTVD interpolant is not set up to extrapolate outside its domain of definition. In this particular case extrapolation is trivial (the SALTVD is constant), but that is not always the case and we've not enabled extrapolation yet.

I am a little hesitant to enable the extrapolation option this close to the release without additional testing. In the 2020.04 release the SALTVD data was simply not used—but recognised in the parser—and that's why it appeared to run.

[OPMUSER]

In that case trap the error and issue an error message, so the user knows how to fix it, and of course back port it into the release. OPM User opmuser0@gmail.com

…

On 02-Nov-20 06:40, Bård Skaflestad wrote: I see this in the release build on my local machine. The immediate cause is that the |SALTVD| table covers the range of 5000 to 5500 ft, but that the top of the formation is at 8325 ft and the |SALTVD| interpolant is not set up to extrapolate outside its domain of definition. In this particular case extrapolation is trivial (the |SALTVD| is constant), but that is not always the case and we've not enabled extrapolation yet. I am a little hesitant to enable the extrapolation option this close to the release without additional testing. In the 2020.04 release the |SALTVD| data was simply not used—but recognised in the parser—and that's why it appeared to run. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2889 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJAQD5UIBFSNWVFRP33DWLSNXPV3ANCNFSM4TGNRCSA>.

[atgeirr]

In general, trying to evaluate outside tables is an error condition but not an unusual one. So perhaps it is not appropriate to use exceptions for such cases? We should at least consider flagging the error in some other way. Perhaps by returning an optional? Although that gives us only the success/fail state, not why it failed, so maybe returning a pair of result and error code is better? If you think this would be too much of a change, we should trap the error somewhere with enough context to tell the user that the SALTVD table was the failing one. Except for missing that crucial info, the existing error message is fine.

[bska]

I had a look earlier today to see how easy it'd be to get something reasonable here. I suppose we could put a hack in place by wrapping the salt concentration derivation in a try/catch block in order to provide additional context to the diagnostic message, but that'd be very specific to SALTVD.

If we want to capture more context, then I think the interpolation functions need to know what keyword they're interpolating, and possibly which curve/table (numeric ID). I haven't thought through the approach of having the interpolation functions return an "expected"-like result type.

For now I'm tempted to release 2020.10 with this as a "known issue" instead and then revisit it early in the development cycle for 2021.04.

[joakim-hove]

For now I'm tempted to release 2020.10 with this as a "known issue"

This is an issue in not much used functionality; it is not a bug as such - but rather a slightly brutal error handling, it has never behaved any differently. I strongly support shipping the release as is without a last second change to improve this error message.