Time delays in energy transport

[p-snft]

For some energy carriers, i.e. heat and gas, delays in the networks play a relevant role. For large networks, transport from one location to the other can take even longer than one time step in the model.

I see two ways to tackle this:

• Delay component
• Delay flow

At the moment, I believe the latter option is more intuitive and adds less complexity to the model.

[jnnr]

Some arguments for implementing this as a component:

• A delay will normally occur in pipes or links (not electrical links, though), which are components.
• Results handling can become complicated when it is not clear which end of the flow, input or output, is meant by the flow variable.

[fwitte]

Things to consider:

• flow reversal with the next (n-th) timestep from now
• storage effects of pipelines with compressible fluids

[p-snft]

There are two PRs that want to model HeatPipeline (#619) and GasLine (#722) to model other aspects than delay.

[robbiemorrison]

I imagine the following openmod forum posting is highly material to this discussion:

• https://forum.openmod.org/t/minimum-storage-time-biogas-digester/2940/4

The formalization was based on state information held by components. The supported transport delays applied to information as well as physical flows. The wider context was dynamical systems behavior and extended well beyond simply capturing transport delays. Perhaps this more fundamental approach is warranted in oemof?

[p-snft]

At the dev meeting (oemof/oemof#96), we discussed that an implementation in/as a component would be more logical from the graph theoretic perspective.

[jnnr]

A related feature: Forcing one flow to be idle for a defined time before another can be active. Can be applied e.g. for a storage reactor which has to rest after charging before it can be discharged. Implemented in #852