search

oemof / oemof-tabular

Load oemof energy systems from tabular data sources.
https://oemof-tabular.readthedocs.io/
BSD 3-Clause "New" or "Revised" License
7 stars 5 forks source link

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

Closed SabineHaas closed 4 weeks ago

SabineHaas commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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.