Optimize allocation per source in a fixed order

[gijsber]

Use Case RWS Linge: Als regionaal watersysteem uit meerdere inlaatpunten kan worden gevoed is er een bepaalde volgordelijkheid. Wanneer bijvoorbeeld 1 inlaatpunt niet volledig kan worden benut vanwege een lagere waterstand in het hoofdwaterysteem, vindt aanvulling plaats.

If a regional watersystem/network can be fed from multiple inlets, a certain sequence of using inlets should be feasible. When the preferred inlet does not have the water available, the request/setpoint of the second inlet should be adjusted.

This was discussed with members from the RTC tools team. They advocate the goal programming approach, i.e. solve for each source separately in order of their preference.

[SouthEndMusic]

As discussed with @gijsber: we first look at single inlets to subnetworks. When the allocation implementation is more mature, we can consider multiple inlets. The main question to answer at that point is: If subnetworks are viewed as users in the main water network optimization, how is this modelled when the subnetwork has multiple inlets? This can probably be taken into account in the optimization problem formulation, where the sum of the flows to the multiple inlets together are taken to be the flow to one user.

[gijsber]

from @SouthEndMusic #565 moet ook nog gedaan worden. Mijn huidige aanpak ondersteunt nu wel meerdere edges vanuit het hoofdnetwerk naar een en hetzelfde subnetwerk, maar ik weet nog niet hoe een ordering over die edges kan worden meegenomen in optimalisatie, anders dan dat de flow vanaf elke inlet individueel wordt getrackt in het subnetwerk, wat het optimalisatieprobleem wellicht een stuk complexer maakt

[gijsber]

Hi @SouthEndMusic, As long as we only track and add a objective function term (i.e. cost) to the inlet edges, the complexity increase will be limited.

We really will get expensive as soon as all edges in the allocation_subnetwork need to get a cost to enable prioritization over sources, as any small cost factors will make the optimal solution less pronounced

[SouthEndMusic]

This is the first step in the new plan for allocation development as worked out on 27-5-2024. Steps:

• [ ] Make the source order per subnetwork a required input. This is a breaking change for models with allocation, but we take that for granted at this point. External modelers won't suffer much problems from this as allocation is hardly used yet.
• [ ] Implement the allocation optimization per source. Things to keep in mind:
• There are some sources that are not explicitly in the input but are introduced by the allocation algorithm. These are the buffers voor fractional flow and level/flow demand. These need an automatic place in the ordering. I think it makes sense that basins (level boundary) come before everything else, then all the explicit sources and then the buffers (so that the buffers can be filled by the other sources).
• [ ] Update documentation with basic examples to explain the concept of allocation

[gijsber]

Hi @SouthEndMusic (@visr). I've been think a bit, to limit the complexity and the amount of data to be specified (decisions to be made by the modeller where he doesn't care):

1. By default use basin excess water as a first source for users that are connected to this specific basin
2. Then use by default other sources within the subnetwork (order does not matter)
3. Then use sources from main network where order is specified by the modeller.