oemof/oemof-solph

Add flow groups

henhuy opened this issue · 1 comments

I want to implement grouping of flows into a flow group like in https://calliope.readthedocs.io/en/v0.6.8/user/advanced_constraints.html#the-conversion-plus-tech

Within a group, flows are shared between input/output flows (logical OR) to produce/consume an input/output unit. Between input/output groups or single input/output flows, every group/flow contributes to producing/consuming an input/output unit (logical AND).
See also fictional example https://calliope.readthedocs.io/en/v0.6.8/user/advanced_constraints.html#complex-fictional-technology

Before, I wanted to add a Multi-Input-Multi-Output converter capable of above mentioned flow groups (see working example: #1011), but as @p-snft pointed out - grouped flows could be integrated into oemof.solph as a more general approach. So I'm trying to refactor my first approach.

Current implementation idea is to introduce a FlowGroup class which can be initialized with multiple flows and which can be used as input/output instead of a single Flow to any component. Additionally, min, max and fix flow shares for this group can be set, which define shares between flows for each timestep.
Example:

b_gas = Bus(label="gas")
b_hydro = Bus(label="hydro")
b_electricity = Bus(label="el")

gas_hydro_group = FlowGroup(
    label="gas_hydro",
    flows={b_gas: Flow(), b_hydro: Flow()},
    min_flow_shares={b_gas: 0.4}
)

converter = Converter(
      label="conv",
      inputs=gas_hydro_group,
      outputs={b_electricity: Flow()},
)

Internally, buses are be connected to converter as before, but an additional Variable for the flow group is created, which gathers related flows and sets up flow share constraints. As far as I can see, this would need changes in oemof.netwok.Node and/or oemof.netwok.Entity in order to add input/output groups there. Additionally, oemof.solph.Model has to be adapted in order to init flow group indexes and set related flow share constraints.

I think the groupings in oemof.network might already do the job. Still, they need to be more user friendly and considered for result processing. I will ask @gnn at the dev meeting.