Extrapolating the LinearInterpolation

[visr]

We use the LinearInterpolation from DataInterpolations for Q(h), A(S) and h(S) relations, the last two provided by users as A(h) once #225 is fixed.

It's important to control the extrapolation behavior, e.g. what happens if h is below the lowest h in the table, or above the largest. We currently have the default behavior of LinearInterpolation, which is linear based on the slope of the last segment. Visually:

I think the linear extrapolation on the high end is fine, since generally the trend continues there, rather than stop. On the low end however we have a different situation, where we should keep it constant instead. So I think this is desired:

There is no direct option for this in DataInterpolations, but it can be achieved by prepending an entry in the table, using prevfloat on the input, and the same output to get a horizontal segment.

Q(h)

• First Q must be 0 Stricter TabulatedRatingCurve validation #1469
• If h is lower than minimum, keep it 0. Stricter TabulatedRatingCurve validation #1469

A(S) and h(S), provided by a user as A(h)

• First A must be >0. Interpolation validation #438 undone in Avoid basin areas becoming 0 #472
• Second A must be larger than 0. Interpolation validation #438
• If S is lower than 0, do constant extrapolation. In principle the solver should prevent S < 0, but good to do this for safety. This way the water level can't be below the bottom, and the area not below 0. Superseded by Negative storage check #1425.

The interpolation input, level, gets sorted. We currently don't enforce that the interpolation output, Q or A, are increasing (or staying constant). In most cases you want this, but it's possible to image scenarios where you don't. A bit contrived, but:

A decreasing surface water area is possible if you think about fishbowl or cave like profiles. And for Q(h) naturally this typically won't happen, but it could be of interest if you want to encode steering behavior without separate control rules.

• Since it is quite rare, and in most cases a decreasing Q or A is a user error, I think we should start enforcing this. If there is a need for it in the future, we could add config options to enable decreasing Q or A, to allow the user to say, I know what I'm doing, don't get in my way.

• For Q(h) a single row is probably fine, but for A(h) we need at least two, where the h is increasing, otherwise you cannot have storage.

[SouthEndMusic]

In a basin profile table there should never be the same level twice, it might be good to validate this.

[gijsber]

problem also experienced by @Fati-Mon