Closed SabineHaas closed 4 weeks 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?
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..
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.
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...
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.
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
andCommodity
.Not sure about
Load
andExcess
as we usually connect them to only one bus. However, in theory one could use them with multiple inputs.