Adding subnodes in Reservoir silently overwrites GenericStorage inputs

[jnnr]

In short: GenericStorage expects a single input and a single output. If you add inputs or outputs by adding subnodes you may throw out the original input flow from the constraints.

Problem By adding the subnode "-inflow" https://github.com/oemof/oemof-tabular/blob/ab58d8c3035b6e97d9d45169832745de11e5bb36/src/oemof/tabular/facades.py#L248 the inputs Flow from the Bus to the Reservoir gets overwritten in the GenericStorage's balance constraints.

You can see this by either looking into the LP-file or calling m.pprint().

This happens silently in the background, which can be a problem. For example, if one wants to model a Reservoir with a pump.

Also, for other types of facades this is problematic. E.g. implementing a battery electric vehicle, which can be thought of as a storage with an additional Sink describing the drive power of the vehicles. This is where I originally stumbled over the issue.

Have a look here for an (not yet finished) Bev facade and the script to test it.

How does it happen? The Reservoir facade inherits from GenericStorage. In line

https://github.com/oemof/oemof-solph/blob/4419d0d777b0240bbcac109891cfd90d122537f2/src/oemof/solph/components.py#L372

a dictionary describing the inputs is created, which only keeps the first entry of a list. Some lines below, when the constraints are created, this dictionary is used

https://github.com/oemof/oemof-solph/blob/4419d0d777b0240bbcac109891cfd90d122537f2/src/oemof/solph/components.py#L476

This is how the Flow gets kicked out of the equation. The reason is that solph's GenericStorage was not designed to have more than one input and output, which happens once you have subnodes. As a consequences, the behaviour of the flows in Reservoir works only by conindidence. If the flows would appear in a different order in the list, the subnode-flow would be out of the storage balance constraints.

Do you have any ideas what I could do without having to roll up everything in GenericStorage?

[jnnr]

A possible workaround would be to avoid using subnodes for these applications and instead use the fixed_losses_absolute attribute of GenericStorage to model the inflow/drive power (for reservoir and bev).

[simnh]

I see the point, but for the Reservoir, it was exactly designed like this: replacing the inflow by another flow coming from a sink but still using the storage equations.

Every facade can only be created based on an existing oemof class. But this can also be a bus, so taking a bus and then connecting everything to it, even with more buses and connections, should not be a problem. This would then be a small sub-network for the energy system object. The important thing for the subnodes attribute is, that every component/bus created in the init of a facade is also added to the energy system.

[jnnr]

Could use the functionality of oemof.solph 0.4 to replace the source by using the constant loss term instead. This will allow to use the inflow of the storage (e.g. as pump).