Fillspill: Passflow satisfies min/max parameters #8
Conversation
| min(q_out_forh_target - q_spill, parameters["Reservoir_Qmax"]), | ||
| ) | ||
| elif current_h == parameters["Reservoir_Htarget"]: | ||
| self.apply_passflow() |
There was a problem hiding this comment.
This was the only place where self.apply_passflow() appears to be used. Could be a good reason to clean it up altogether, unless we see future potential usecases for it, perhaps even as an isolated function (only scheme applied). What do you think?
There was a problem hiding this comment.
And just to check, it seems that the behaviour of the total scheme has now not changed, except for the exact scenario that H == H_Target, correct? In that case it now considers P/ET to keep H at H_Target, while obeying QMax/min. For all scenarios of H being smaller than H_spill, it already was going okay.
Is that also what led to this adjustment, or where there different issues identified?
There was a problem hiding this comment.
self.apply_passflow() is an independent required scheme so we leave it in. It just does not meet the requirements to be re-used within the fillspill scheme.
And yes, outlined in the description of the PR, the issue was related to the exact case where passflow was triggered (when H=H_target) so only this part of the scheme is adjusted by this PR.
Within fillspill, passflow is triggered when the current water level is equal to the target level. However
Thus we use calc_q also for the passflow part of the fillspill scheme. When flows are within the min/max range results are unchanged other than we set Q_turbine instead of Q_out. when inflow is outside of the min/max range, Q_turbine flow obeys the range. (an example of this case is seen in this issue https://issuetracker.deltares.nl/browse/RTCTOOLS-1428).
Note: we already check if the current water level is above the spill level, so we are sure that Q_spill is zero.
Dependencies are also updated for rtc-tools-interface to resolve issues with installing a prerelease.