Facades inherting from Sink and Source should be able to have multiple inputs / outputs

[SabineHaas]

Sink and Source can have multiple inputs / outputs in oemof.solph.
With PR1088 in solph the Warning indicating that len(outputs) != 1 is removed.

Facades to adapt: Dispatchable and Commodity.

Not sure about Load and Excess as we usually connect them to only one bus. However, in theory one could use them with multiple inputs.

[Bachibouzouk]

I agree that the possibilities from the core component of oemof-solph should be kept for oemof-tabular. It is currently not the case? Do you have a usecase datapackage to illustrate this? If yes could you share it?

[henhuy]

I would say that Dispatchable and Commodity are just implementations of a Source - aka they don't need to cover all possibilities from Source as they server different needs.
IMO, I would implement a new Facade which might be a child of Distpatchable/ Commodity with ability to add emissions..

[Bachibouzouk]

aka they don't need to cover all possibilities from Source as they server different needs.

Fair point

IMO, I would implement a new Facade which might be a child of Distpatchable/ Commodity with ability to add emissions..

I just see a problem here in the use, then you could create CommodityWithEmission which would differ from Commodity in the sense you can add emissions. I would prefer to add such broad option directly into Commodity rather than finding a new name for a child class and end up having too many components.

On the other hand allow more than one bus put some stress on the formatting of the arguments "amount" and "marginal_cost" as they might potentially be associated with more than one flow. An other argument would need to be introduced to allow constraining one flow with another one.

[henhuy]

aka they don't need to cover all possibilities from Source as they server different needs.

Fair point

IMO, I would implement a new Facade which might be a child of Distpatchable/ Commodity with ability to add emissions..

I just see a problem here in the use, then you could create CommodityWithEmission which would differ from Commodity in the sense you can add emissions. I would prefer to add such broad option directly into Commodity rather than finding a new name for a child class and end up having too many components.

On the other hand allow more than one bus put some stress on the formatting of the arguments "amount" and "marginal_cost" as they might potentially be associated with more than one flow. An other argument would need to be introduced to allow constraining one flow with another one.

I understand both points. But as you already mentioned - allowing multiple busses on a facade is difficult.
One could allow "amount" and "marginal_cost" to be a dictionary optionally, and check in facade whether it is given as float or dict of floats - but this blows up Facade and removes simplicity...

[SabineHaas]

I understand your points and I hadn't been fully aware before, what the oemof.tabular facades are meant to be. It makes sense to me that they are more specific implementations and that we add new facades, see #177
If you agree I would close this issue now.