Allow non-ascending tabulated rating curves

[rbruijnshkv]

What
Currently it is mandatory to have a strictly ascending tabulated rating curves (TRC's). This assumption aligns with natural hydrological systems, where discharge typically increases with water level. However, in highly regulated systems—such as the Netherlands—this assumption does not always hold.

Many weirs in these systems dynamically adjust their crest levels based on water levels or discharge, resulting in TRCs that are not strictly ascending.

Why
While the national hydrological model (LHM) is not likely to encounter this issue as it is built from data that does not include control structures, the Peelvenen project follows a different workflow. Here we have developed a D-HYDRO to Ribasim model converter. As D-HYDRO contains control, non-ascending TRC's become a fact. In the majority of the TRC's it works fine, but for a substantial part it doesn't

We retrieve the (sometimes) non-ascending TRC's from D-HYDRO, and convert it through a post processing step into an ascending one. Since D-HYDRO represents our "ground truth," this enforced correction introduces unintended differences. In most cases, the corrections are minor. However, in a substantial number of cases, the effects are significant.

How
From discussions with @visr, it appears that removing the strict ascending check should not cause software issues, as it was primarily implemented to protect users from non-logical TRCs.

As shown in the images below, caution should (maybe?) be taken if the discharge drops below 0, as negative discharge are (maybe?) not desired. Sometimes they are, but I can imagine this poses (maybe?) quite some challenges in terms of software.

Additional context
We write the _un_correct and corrected Q(h)-curve for each TRC. Sometimes the deviation is small:

But sometimes the effects are significant:

Lastly, sometimes they are non-ascending only which are also being correct:

Lastly, sometimes the TRC is acting quite funky, as shown below. Again, this occurs not that often, but I thought it is good to show you a variety of cases.

[Huite]

I think I agree with @visr that mathematically, this isn't a problem at all.

Maybe worth remarking: it does open the way for more non-uniqueness for steady-states, but we already have multistability in principle due to how control mechanisms work.

Final concern is protecting users from accidental, my guess is that non-monotonic rating curves are (hopefully) somewhat niche. Not sure you'd want to introduce a separate NonMonotonicTabulatedRatingCurve though...

[rbruijnshkv]

Small update from us from a user perspective. I discussed this internally with our project team for the Peelvenen, and concluded that it is unlikely this feature will be (de)implemented within the schedule of the Peelvenen. Since we need to finalize the (stand-alone) models for the Peelvenen soon, we do not expect to be able to use the outcome of this issue for the current project.

It would thus be useful to have the option to not be obliged to use monotonic rating curves in the future, but there is no urgency for the Peelvenen project.