Calcul de l'hydrogramme au-delà de la validité de la courbe

[benRenard]

BaRatin calcule un hydrogramme même quand la valeur du limni dépasse la gamme de définition de la courbe de tarage. C'est plutôt bien, mais il faudrait que ce soit spécifié sur le graphique de l'hydrogramme, genre un fond coloré qui précise qu'on est au-delà de la définition de la CT. Peut-être faudrait-il aussi le préciser lorsqu'on exporte l'hydrogramme, genre une colonne avec un code qui précise ce truc là.

Ou alors remplacer ces valeurs avec un code lacune

[IvanHeriver]

A toggle button could be at the bottom of streamflow series plot that show/hide red areas outside of the rating curve definition range. The maxpost rating curve and the min/max stage values should be used to define the min and max streamflow values.

[IvanHeriver]

as suggested by @JeromeLeCoz (let me know if I got your idea wrong), computing hydrographs outside of the stage range defined as valid when creating the rating curve should not be allowed. In cases where the stage time series contains values outside of the valid stage range, we should (1) trigger a warning and (2) insert missing values instead of the computed discharge values

[benRenard]

I'm not sure I agree with this behavior, for 2 reasons:

1. it's not entirely clear that the stage range specified in the 'rating curve' panel is a validity range: it could be interpreted as the stage range used to plot the curve, which is not quite the same thing.
2. I'm in general not a big fan of "repressive" implementations like this, that create a problem (inserting NAs for a computation that is in fact feasible) to prevent the user doing a mistake. I prefer a "liberal" implementation that would emit a clear warning (a message and something on the plot), but let the user proceed if she/he wants.

[JeromeLeCoz]

I don't remember what I suggested precisely but I agree with Ben's 2 points. However, if I suggested something, it was not based on the stage range defined to compute the rating curve (the RC grid). The following might make more sense:

• add two optional fields (in the hydraulic config tab) to let the user define the min and max stage between which the config is assumed to be valid. Doing this is not absolutely compulsory but it is good practice to define such stage bounds. They have no reason to be equal to the min/max stage bounds of the prior or posterior RC grid. They relate to the physical assumptions of a given hydraulic config, hence of a given RC. Logically, the user should not compute the RC outside of the min/max stage bounds of the config.
• and logically also, if defined, these bounds should not be exceeded when computing the discharge series (missing values + warning).
• these hydraulic config validity bounds should be given in the RC equation, if available.

This approach seems consistent with Ben's points 1 and 2. What do you think?

[benRenard]

OK makes sense, since with this solution it's up to the user to decide whether she/he wants to enforce a validity range. I still have a doubt about the relevance of a "min" stage value though: how do you define it? Is it the activation stage of the first control ? But it's kind of useless since Q is zero when h is smaller than this activation stage anyway. And I fear it could even create confusion or problems because this activation stage is estimated - so we'll have to handle possible conflicts between the "min" stage and the estimated activation stage, which sounds like an unnecessary complication. I feel that only the "max" stage is really useful.