Conversation
…ribute add tsam logic and weighting to additional total limit of costume attribute
p-snft
left a comment
There was a problem hiding this comment.
At the moment, I would see this as a Showcase entry. Sure, the constraint is written in a generic way, but an example works without tests and discussions about the API.
(@gnn and I were discussing how to harmonise different types of variables, so that a "flow of money" would be constrained using the same code as energy flows. But maybe, this would rather be something for solph 2.)
|
|
||
| Installation requirements | ||
| ------------------------- | ||
| This example requires oemof.solph (v0.5.x), install by: |
model.GenericInvestmentStorageBlock.invest[st, p]
* getattr(storages[st][0].investment, keyword).get("cost", 0)
gets always calculated 2 times in the constraint. Idk where bug comes from.
…e offset was always set
p-snft
left a comment
There was a problem hiding this comment.
Thanks for your efforts. I see the following issues that should be addressed before a merge:
- The approach seems to duplicate a lot of
additional_investment_flow_limit- which it extends. From my point of view, we do not really need both. So, you might just extend the existing constraint, rename it and provide a transitional wrapper. (You can have keyword arguments to still only consider flows and no offsets.) - The constraint you introduce is completely untested.
|
Thank you for the feedback. To specify the offset or cost per unit of a custom attribute, I used the following:
The old version used instead:
This is relevant at the moment the constraint is set. If I put a wrapper around the old constraint, it only works if
|
I see the point. As this is not about about arguments to the function only, a classical wrapper will not do. Maybe, just write a deprecation warning for the old constraint, telling that the new one should be used in the future. In that case, I'd suggest a test that proves that both constraints provide the same result if PS: The name "cost" might be misleading. Maybe, just be mathematical here and call them "linear" and "offset". |
…vestments' into feature/custom_attributes_for_investments # Conflicts: # examples/emission_constraint/emission_constraint_invest.py # examples/emission_constraint/emission_constraint_invest_and_flow.py
| import logging | ||
| import os | ||
|
|
||
| from PIL.ImageChops import offset |
Check notice
Code scanning / CodeQL
Unused import Note
There was a problem hiding this comment.
I also do not get why you import this.
| from oemof import solph | ||
|
|
||
|
|
||
| def main(optimize=True): |
Check notice
Code scanning / CodeQL
Explicit returns mixed with implicit (fall through) returns Note
| """ | ||
|
|
||
| import pandas as pd | ||
| import pytest |
Check notice
Code scanning / CodeQL
Unused import Note test
|
Thank you very much for the feedback. I have implemented all the requested changes. I've also moved all examples that restrict a costume attribute to an example folder and renamed it Emission. Why this? I think this will be much easier for people to find. Also, there is now a better and more consistent structure in the examples with limits of: flow, invest, invest and flow. |
p-snft
left a comment
There was a problem hiding this comment.
I did not repeat the CodeQL comments, but two of those were (and still are) valuable.
| """ | ||
|
|
||
| import pandas as pd | ||
| import pytest |
| import logging | ||
| import os | ||
|
|
||
| from PIL.ImageChops import offset |
There was a problem hiding this comment.
I also do not get why you import this.
Constraints Investments for costume attributes missed the possibility of constraining not only the investment flow, but the sum of investment and operation. Furthermore no OffSet for costume Attributes in investments were considers.
This PR adds both and explains it in an example.
It is handy to have these to run a restricted optimization, as explained in Issue 1171