Fix allocation issue of training model

[gijsber]

The training model has an issue with allocation under the influence of reduction factors.

This needs to be investigated and addressed

[gijsber]

Teams chat:
Hallo allen, hier even een update op basis van discussies met Fatima over een allocatie model voor de Ribasim DSD cursus (en meer algemeen).

Het model dat Fatima heeft opgesteld gedraagt zich niet zoals verwacht, en de reden daarvoor zou ik omschrijven als 'allocatie heeft niet genoeg invloed op wat er in de fysieke laag gebeurt'. Zeker in het geval dat een basin droog valt, domineert de lower storage factor uit de fysieke laag, waarbij alle abstracties worden gekort, en niet in volgorde van demands. Dat maakt het moeilijk om een model met uitlegbaar gedrag te maken. We zouden kunnen kijken of we de lower storage factor kunnen veralgemeniseren om allocatie in acht te nemen, als dat een wenselijke richting is. Dit is specifiek voor het geval waarbij meerdere users met verschillende prioriteiten uit hetzelfde basin abstracten.

Ik herinner me dat Peter een tijd geleden zei dat 'de allocatie laag bepaalt hoeveel users mogen abstracten en het is aan control om te zorgen dat het water daar komt'. Wellicht kan vanuit dat concept een model gemaakt worden

De rol van basins in allocatie is ook conceptueel complex, en hoe de demand van basins bepaalt wordt vanuit een 'tekort schijf' moet misschien ook worden herdacht

De demand kolom in allocation.arrow geeft precies de demand invoer zoals in je eerste plot (maar dan overal geïnterpoleerd/geëxtrapoloeerd)

Bart de Koning
De demand kolom in allocation.arrow geeft precies de demand invoer zoals in je eerste plot (maar dan overal geïnterpoleerd/geëxtrapoloeerd)

Ja dat klopt, en wat is de unit daarvan?

kuub per seconde

In allocation_flow.arrow staat de flow zoals allocatie berekend heeft dat die van bron naar demands moet gaan. Je ziet dat de demand en wat er gealloceerd is precies overeenkomt, er is dus nergens op gekort. Die dipjes in je plot komen dus puur uit de fysieke laag. In de fysieke laag is er dus rond augustus een tekort in het basin waaruit abstract wordt, maar allocatie 'heeft niet door' dat er gekort moet worden, dat algoritme vind dat er genoeg flow van de bronnen komt

Kan je de plot van je schematisatie sturen?

Het ding is dat allocatie alleen maar het subnetwerk als geheel beschouwd en niet naar water beschikbaarheid op basin niveau kijkt, en de fysieke laag doet dat juist wel

Hmm ja, allocatie houdt er geen rekening mee dat er ook water 'verloren gaat' door TabulatedRatingCurve #8

Ja het lijkt er op alsof de fysieke en de allocatie laag niet naar elkaar 'luisteren'. Ik verwacht dat als er te weinig water in de basin is, voorzie demand met eerste prioriteit van water (industrie). Dat betekent dus dat gealloceerd water naar Irrigatie zodanig laag wordt, zodat het gealloceerd kan worden aan industrie. En dat zie ik niet terug.

Ja dat is conceptueel logisch, maar dus niet het huidige gedrag. Mijn idee was om de korting in de fysieke laag te laten afhangen van de gealloceerde waarden. De vraag daarbij is wel wat je met abstracties zonder demand doet. Die zou je dan altijd als 'volledig gealloceerd' kunnen beschouwen.

Verder zou het idd beter zijn als allocatie zich meer bewust zou zijn van 'fysische flows' (zo interpreteer ik die rating curve maar even, als iets wat niet gestuurd wordt).

Je zou wel die rating curve een flow demand met hoge prioriteit kunnen geven, maar dat maakt de schematisatie weer complexer

Bart de Koning
Je zou wel die rating curve een flow demand met hoge prioriteit kunnen geven, maar dat maakt de schematisatie weer complexer

inderdaad niet echt aantrekkelijk denk ik voor een normale gebruiker

Als iemand een idee heeft om deze situatie en het verhaal/verwachtingen goed over te brengen tijdens de training dan hoor ik het graag!

Bart de Koning
Ja dat is conceptueel logisch, maar dus niet het huidige gedrag. Mijn idee was om de korting in de fysieke laag te laten afhangen van de gealloceerde waarden. De vraag daarbij is wel wat je met abstracties zonder demand doet. Die zou je dan altijd als 'volledig gealloceerd' kunnen beschouwen. …

Abstracties zonder demand (bijv. natuurlijke processen zoals verdamping/infiltratie) moet je inderdaad als 'volledig te alloceren' beschouwen

Goed testmodel trouwens. wel wat jammer dat we nu pas achter dit probleem komen

Bart de Koning begrijp ik nu goed dat de tabulatedratingcurve zorgt dat de flow-rate lager is dan waar allocatie vanuit gaat ? Hoe bepaal je de (max) flow-rate waar allocatie van uit gaat ?

Allocatie verdeelt de beschikbare flow vanuit FlowBoundary #1 en Basin #7 over users 6, 9, 10. Dat is niet realistisch omdat TabulatedRatingCurve #8 ook van die flow gebruik maakt maar allocatie daar geen rekening mee houdt

Allocatie ziet alleen bronnen, demands en edge capaciteiten

Vandaar dat de verdeling in allocatie meer zou kloppen als de rating curve een flow demand zou hebben

Nu is het hier ook extra complex omdat er zo veel nodes aan Basin #7 hangen

Bart de Koning
Ja dat is conceptueel logisch, maar dus niet het huidige gedrag. Mijn idee was om de korting in de fysieke laag te laten afhangen van de gealloceerde waarden. De vraag daarbij is wel wat je met abstracties zonder demand doet. Die zou je dan altijd als 'volledig gealloceerd' kunnen beschouwen. …
Martijn denk je dat een low storage factor afhankelijk van gealloceerde flows een goed idee is?

[gijsber]

Hi @SouthEndMusic , @Fati-Mon . I this case it might be rather easy to figure out what the outflow over the rating curve has to be.
Your basin has a LevelDemand, so given this LevelDemand, you can figure out what the related flow-rate over the ratingcurve would be. This flow-rate could be then in background be added as a FlowDemand to your allocation problem, probably with similar priority as the level demand.

of course, this will only work when you have a RatingCurve and a LevelDemand. If you have a rating curve but no level demand, you may use the 'min_level's from the UserAbstraction to figure out what the minimal outflow will be. If these min_levels are not specified, you could consider taking the initial water level of your allocation timestep as a guidance to determine the flowrate you need to account for.

So the sequence to try and determine an internal flowdemand would be:

1. RatingCurve + upstream LevelDemand ->internal FlowDemand
2. RatingCurve + UserAbstraction.min_level -> internal FlowDemand
3. RatingCurve + initial level at allocation timestep -> internal FlowDemand

In general this use case need to documented very well (e.g. with all variations from above explained) such that the modeller understands how the algorithm response and how this can be influenced.

[gijsber]

For Pumps, outlets and resistance connectors, it is probably more complicated to derive general rules how to define an internal FlowDemand