test_satfunc is broken

[akva2]

The 'test_satfunc' is rather broken, or rather it highlights an issue with current code that warrants investigation.

Round-off causes significant application behavior in the interpolation classes. In particular, 6 tests break on x86 due to this. In particular values in 'dkrds' arrays significantly differ. This is due to evaluation of derivatives in kinks - undefined behavior in the first place. Due to different rounding we get the 'other' wrong value on x86. Note that this is not tied to architecture as such, if the code was built on arm it would likely fails as well (but possibly in other ways..)

I reckon the proper fix is to don't try to obtain undefined values.

[andlaus]

I reckon the proper fix is to don't try to obtain undefined values.

I'd like to add that this issue can be also fixed by using C^1 or higher interpolation functions like monotonic splines, but this would result in results which are different from E100. (and thus they're probably unacceptable?)

[atgeirr]

I agree that this is undefined, unless we want to make certain guarantees about what value we return in the kinks. The question has been raised, especially about the exact endpoints. While I love splines, for the purpose of Flow we cannot use the C^1 functions, so the tests must change.

It is not a showstopper for the release however.

[andlaus]

unless we want to make certain guarantees what value we return in the kinks.

that's pretty hard to implement and also wouldn't fix the issue at hand: if the input saturation ends up on the "wrong" side of the kink due to some numerical noise caused by the architecture (think of a difference of e.g. 10^-15), the returned derivative would be completely different anyway.

[atgeirr]

if the input saturation ends up on the "wrong" side of the kink due to some numerical noise caused by the architecture (think of a difference of e.g. 10^-15), the returned derivative would be completely different anyway.

I was thinking of tests that explicitly check the endpoints for example, then it might be possible. However I think we have agreed not to expect any particular behaviour at kinks.

[atgeirr]

@akva2 Is this still a problem?

[akva2]

yes, nothing has changed as far as i know.

[andlaus]

yes, nothing has changed as far as i know.

probably the test should be changed so that it does not check for the derivatives at kinks? testing the behaviour for something which is mathematically undefined is not a very smart idea IMO: normally it just makes the test to be adapted to the implementation and that is what happened with this unit test. (as far as I can see, this applies to the code before and after the switch to opm-material.)

[atgeirr]

I agree, testing at the kinks is inherently bad, regardless of the implementation.