We're planning to use FlexTool for combined water and energy modelling. With hydrological systems, it's often desirable to have delays in the flows between locations. Delays can be useful also for e.g. modelling road transport or shipping.
Status: not in a hurry
Here are some initial thoughts about the possible implementation. The delay could take place already in the flow (in the flow that takes place from the unit to the sink node), which would be more realistic, or then it could happen in the node_balance equation when the flow enters the sink node. The former has the challenge that FlexTool can do one variable flows and in many cases delayed flows would be using this (it's just one way lossless flow between two nodes). With only one variable, it's not possible to distinguish the flow out from the source and the flow into the sink. The latter option could be bit easier to implement, since it would work for all flows. In any case, there needs to be post-processing of results to make the flows look correct (in the first case this is needed only for the one variable flows). Overall, it looks like the latter option is better.
Not for the latter option: In principle, reserves will not work correctly, since the flow entering the sink node is taking place in the earlier (wrong) timestep. However, power systems do not have delays and so far that's the only case where reserves have been needed. Also, if the flow is used in e.g. user constraints, there could be situations where the wrong timing of the flow will be a problem.
Implementing the delays in the node balance equation:
The source node will act the same as before (only the term where "n is sink" will be affected)
Divide the set process_source_sink to two: process__source__sink_no_delay and process__source__sink_delayed. Needs to be created only for flows to a sink node.
New temporal set is needed to map the current t (from the flow perspective) to the future t (from the node perspective) where the flow will enter the sink node. Since the 'n is sink' term takes the perspective of the sink node, the pre-calculated set should be (p, source, sink, d, t, d_departure, t_departure). There, 'departure', means the departure time step of the flow.
Water flows typically spread during long stretches of waterways. Therefore it could be possible to have a parameter for 'spread_share', that would disperse the arriving flow over multiple time steps. However, this requires additional input data and would also complicate post-processing calculations. Hence, TBD.
We're planning to use FlexTool for combined water and energy modelling. With hydrological systems, it's often desirable to have delays in the flows between locations. Delays can be useful also for e.g. modelling road transport or shipping.
Status: not in a hurry
Here are some initial thoughts about the possible implementation. The delay could take place already in the flow (in the flow that takes place from the unit to the sink node), which would be more realistic, or then it could happen in the node_balance equation when the flow enters the sink node. The former has the challenge that FlexTool can do one variable flows and in many cases delayed flows would be using this (it's just one way lossless flow between two nodes). With only one variable, it's not possible to distinguish the flow out from the source and the flow into the sink. The latter option could be bit easier to implement, since it would work for all flows. In any case, there needs to be post-processing of results to make the flows look correct (in the first case this is needed only for the one variable flows). Overall, it looks like the latter option is better.
Not for the latter option: In principle, reserves will not work correctly, since the flow entering the sink node is taking place in the earlier (wrong) timestep. However, power systems do not have delays and so far that's the only case where reserves have been needed. Also, if the flow is used in e.g. user constraints, there could be situations where the wrong timing of the flow will be a problem.
Implementing the delays in the node balance equation:
process_source_sinkto two:process__source__sink_no_delayandprocess__source__sink_delayed. Needs to be created only for flows to a sink node.