Add capacity_potential as attribute to facade_attrs files

[MaGering]

This PR resolves #20.

I've added the attribute capacity_potential to the following files in oemoflex/model/facade_attrs/:

• asymmetric_storage.csv
• storage.csv
• volatile.csv
• conversion.csv

I chose the description analogous to the one in the docstrings of the respective class in oemof.tabular.facades. In the storage classes it was: Potential of the investment for capacity. And in the other two: Max install capacity if investment.

[jnnr]

Thanks for your work!

Still open:

• Can you please do the same for storage_capacity_potential?
• Please find out what capacity_potential and storage_capacity_potential mean. Is it an upper bound of the sum of existing capacities and invested, or only on the invested? For greenfield investment this would be the same, for brownfield not.

[jnnr]

Looks good already. Please consider my previous comment and the 2 todos there.

[MaGering]

* Please find out what capacity_potential and storage_capacity_potential mean. Is it an upper bound of the sum of existing capacities and invested, or only on the invested? For greenfield investment this would be the same, for brownfield not.

I don't know if it answers your question but what I found out is the following:

1. Both, capacity_potential and storage_capacity_potential, are attributes in investment class.
2. Only storage components have both attributes: capacity_potential and storage_capacity_potential.
3. storage_capacity_potential is the upper bound of the "Invested storage capacity [MWh]".
4. capacity_potential is the upper bound that is set on the inflow of the component. -> "Invested capacity [MW]".
5. In the facades you can set an initial capacity with capacity on the inflow, which influences "Invested capacity [MW]". This initial capacity is subtracted from the invested one (or at least this happened in the example I tested it on).
6. But as it appears to me, you can not set an initial capacity of the storage, because storage_capacity is not implemented in the facades, is that correct?

[jnnr]

@MaGering: Can you please resolve the merge conflicts? They occur because the order of the expected data has changed in dev (the columns are ordered alphabetically now).

[jnnr]

Thanks for your work. Looks good!

Open question (can be a separate issue): Does the capacity_potential work for assymetric storage? There are two capacities: capacity_charge and capacity_discharge

[MaGering]

Thanks for your work. Looks good!

Open question (can be a separate issue): Does the capacity_potential work for assymetric storage? There are two capacities: capacity_charge and capacity_discharge

You're right, @jnnr! I was not aware of this.

I examined the storage's facade in the following script:
examine_oemof_facade_storages.csv

The example shows that in order to restrict the invested capacity (MW) of the asymmetric storage, you have to pass a value with capacity_potential_charge and/or capacity_potential_discharge instead of capacity_potential. I'm going to adapt this in this PR.

I hope this example also helps you understanding the influence of the parameters on the results as I described here.

In order to run the script you'll have to install oemof.solph in your oemoflex environment and most likely adapt one or more imports of oemof.network to oemof.network.network because oemof is installed with the installation of oemof.tabular in install_requires of oemoflex' setup.py. As far as I'm concerned oemof is obsolete and might lead to errors when using it. Should we consider dropping oemof from the install_requires?

[jnnr]

I examined the storage's facade in the following script: examine_oemof_facade_storages.csv

Thanks for the example, @MaGering! This is really helpful. I had to change to oemof.solph version 0.3 and make some adjustments first, but then it worked. The behaviour of the storage (the symmetric one) is strange. The capacity_potential seems to apply only to the output. We have to study this in more detail

I transfered your example to a test which is now up on this branch: #42

[jnnr]

Thanks for your work, @MaGering! We can already merge this, but keep in mind that constraining the potential for investment does not work as intended yet. This is addressed by introducing tests that should be fixed in a separate PR #42 .