Add User node type

[gijsber]

data definition

• requested abstraction [m3/s] (double) dynamic timeseries via file or set at runtime via de Metaswap coupler)
• actual abstraction [m3/s] (double, updated at runtime by the allocation algorithm)
• return percentage [%] (double between 0-100) static

additional input for allocation algorithm [#349]

• priority [-] integer>0, static, lowest number is most important

default behaviour (without allocation algorithm)

• extract water from basin, reduce/stop abstraction when the minimum level/volume is approached
• actual abstraction = requested abstraction,
• extract water based on availability/first come, first serve

when allocation algorithm [#349] is activated

• allocation algorithm updates (cut back) actual abstraction as needed based on priority such that higher priority users get their water under dry conditions

[visr]

I believe this can be closed in favor of #14.

[gijsber]

H'mm I do not if this one can be closed. even if we do not run in 'allocation' mode with priorities, we should allow users to abstract water on a first come first serve basis. We need a User node type

[visr]

Ok, re-opened and renamed the issue to "add User node type".
I think this node type would be like the FlowBoundary, except that it has a priority, and a possible return flow.

[SouthEndMusic]

As mentioned in #293, the abstraction flow rate of a user should be a DiscreteControl condition (listen) variable

[SouthEndMusic]

I came up with some questions during the implementation:

1. When a user returns water, do they do so over the same edge as the abstraction? Or should the user have an incoming edge over which it abstracts, and potentially an outgoing edge over which it returns?
2. Can a user return water that did not come from inside the model, or is that more a usec ase of a FlowBoundary node?
3. Is the priority a mandatory input, or should it be optional and default to say the lowest priority?
4. Should the input for the User nodes have a static and time table?

[gijsber]

1. a user should have an incoming edge and an outgoing edge. The outgoing edge can go to the same or a different basin.
2. if a modeller wants to return water that did not come from the basin (or a coupled model like Modflow), a FlowBoundary node needs to be used
3. best to make it mandatory
4. the Demand should be in the static and the timetable. Priority can be in static only

[SouthEndMusic]

Some more questions:

1. I'm not sure what our conclusion was on where the level comes from down to which a user is allowed to abstract. Should we bring back the basin-related minimum level? Or should it be associated with the user? I see that you also want to be able to set a minimum volume, I presume that is always for a specific basin.
2. Is the return flow always immediate? I can imagine that a user can hold an amount of water before it is returned. The implementation of that might be quite fiddly though, for instance regarding the water conservation validation. Essentially then the User node must have state.

[gijsber]

1. let's define this with the user, in the static table only untill we realize it should be dynamic
2. yes, immediate. In practice some delay may occur, but generally there will be no information available to parameterize such a delay. Eg, for Industry, you are likely to know an annual or monthly abstraction rate (mostly from the permit or a report) and if you are lucky a daily series of abstractions and return flows.