Compute water demand for LevelControl

[gijsber]

Water level control can be an important demand in the water allocation context

We should be able to compute the water demand for level control in the coming timestep (given the basin storage and known boundary fluxes) to:

• preserve the minimum water level of a basin (highest allocation priority)
• preserve the target level (priority to be decided by user)

advanced feature: allow the modeller to deactivate preserving minimum water level from the allocation process (if you have too little water to preserve all min.levels in the network, you can then still make a choice as a modeller, which minim.levels to include in the allocation process )

[visr]

Looking at the example model with discrete control: https://deltares.github.io/Ribasim/python/examples.html#model-with-discrete-control

That example controls flows over pumps to a LevelBoundary, which is an infinite source of water. Also, when the water level is not within bounds, it only sets a fixed flow rate for a pump.

For allocation, we will probably use fixed time windows, for instance one day. At the start of the day we need to calculate the volume of water we'd need to reach the target, and be able to ask that as a demand to the allocation procudure.

[SnippenE]

Check if this is related to #660.
We start with #660 to handle vertical fluxes. This should at least be able to maintian water levels by compensating e.g. evaporation fluxes.

This issue is for generating extra demands to reach target water levels.

[SouthEndMusic]

As discussed with @visr, we won't make the minimum abstraction level a property of basins, this remains a property of users.

Therefore the reference level(s) which allocation uses to see whether a basin either is a source or has a demand must come from control. The simplest case for this is PID control, where the target level is clear (and no minimum level is present). Then in terms of implementation:

• When processing subnetworks for allocation, for each basin it is checked whether it is PID controlled and this is flagged.
• For allocation optimization, for each basin that is PID controlled the net supply (if positive) or demand (if negative) is calculated as the 'disk of water difference' between current level and target level divided by the allocation timestep plus the average over the coming allocation timestep of the vertical fluxes. If positive it is taken as a source, if negative it is taken as a highest priority demand.

For discrete control this is more complex, because of the generic nature of discrete control. Maybe this calls for a new specialized interval control node, as this seems to be an important use case.

[gijsber]

from @SouthEndMusic
#564 is wat mij betreft een belangrijk issue dat nog moet worden aangepakt. Ik interpreteer deze als basins meenemen in allocatie als sources danwel 'users' afhankelijk van hun level. Hier moeten dan wel flows en storages worden vergeleken, waarbij mijn idee was om de allocatie tijdstap als omrekenfactor te gebruiken.

[gijsber]

From Teams:Hi beiden. Ik ben aan het kijken naar compute water demand for LevelControl · Issue #564 · Deltares/Ribasim (github.com). Zoals in de discussie bij het issue blijkt, zijn we eerder tot de conclusie gekomen dat het minimumpeil voor een basin dat door allocatie moet worden gehandhaafd een eigenschap van users is en blijft. Vanuit hydrologisch oogpunt logisch, maar qua implementatie lastig. Als deze minimumpeilen moeten worden gehandhaafd door een demand van basins af te leiden (met hogere proriteit dan alle user demands), moet een basin een uniek minimumpeil hebben, wat nu niet per sé het geval is als meerdere users uit hetzelfde basin onttrekken. En als een basin geen ontrekkende user(s) heeft, heeft het basin helemaal geen minimum peil. Wat te doen?
Misschien zijn het minimum peil waarbij een user nog kan ontrekken en het minimum streefpeil van een basin ook niet altijd gelijk?

[gijsber]

RE: from peter:
Mogelijk dat we onderstaande bewoording tot verwarring leidt, maar ik zat het volgende te bedenken.
elke user/onttrekker blijft onttrekken zoals hij nu doet totdat hij tegen zijn/haar minimum peil aanloopt.
de peilbeheer vraag is eigenlijk het compenseren van natuurlijke verliezen max(neerslag-verdamping+drainage-infiltratie,0) zodanig dat een bepaald peil gehandhaafd wordt gegeven de begintoestand.
kunnen we deze peilbeheer vraag vormgeven door dit via een user node aan een basin te koppelen met een prioriteit en een minimum peil zonder een flow rate (evt met een vlag 'control_level=true'). Die flow rate wordt dan door de rekenkern ingeschat op basis van het (verwachtte) natuurlijk verlies en de huidige waterstand(/buffer).
in allocatie wordt deze peilbeheer vraag beschouwd als een user met een bepaalde prioriteit die water gealloceerd moet krijgen
in de terugvertaling naar de rule-based simulatie vindt voor deze user geen update van de onttrekking plaats (want dit natuurlijk proces is niet te stoppen)
Misschien tijd om in het issue verder te filosoferen of voor een korte face-to-face sessie morgen

[gijsber]

Hoi Bart, ipv dat we alles in 1 user node type proppen moeten we misschien twee of drie nodes types introduceren die specifiek voor allocation een rol hebben: UserAbstraction (=huidige user)), LevelDemand (=above) en InstreamDemand. Instream demand is een minimum flow die je in je allocatie berekening op een connector node wil realiseren. LevelConroldemand en Instreamdemand hebben geen rol in de rule-base simulatie maar zijn alleen bedoeld dat er als onderdeel van de allocatie berekening voldoende water in het systeem is/komt/blijft.