Feature/objective function weighted sum

[minhki95]

• What functionality does it implement?

  • This preliminary pull-request is implementing a functionality to model cellular energy system as it was introduced by the VDE (cf. VDE Studie (2015) „Der Zellulare Ansatz“)

• Where is it located?

  • Modifications have been made in the oemof-solph repository but also in the oemof-network repository see the PR below:
    Add cell_list attribute to Node class oemof-network#18

  • In oemof-solph several components which are linked to the objective function have to be modified. So far the following components have been edited for this:

• src/oemof/solph/blocks/flow.py
• src/oemof/solph/blocks/investment_flow.py

• What is the idea?
  • Preliminary motivation is to test different approaches to model and solve cellular energy systems. In my first attempt I implement the weighted sum objective functions which is the simplest approach. For this, the objective function is formed as the sum of the seperate objective function terms of every declared cell. Note that every cell can contain other cells, hence, objective expressions of components which are contained in multiple cells are also represented in the objective function multiple times. See the sketch below,
    

[pep8speaks]

Hello @minhki95! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file src/oemof/solph/blocks/flow.py:

Line 120:20: E131 continuation line unaligned for hanging indent
Line 129:20: E131 continuation line unaligned for hanging indent
Line 279:29: E123 closing bracket does not match indentation of opening bracket's line

• In the file src/oemof/solph/blocks/investment_flow.py:

Line 434:80: E501 line too long (86 > 79 characters)
Line 435:80: E501 line too long (84 > 79 characters)
Line 441:80: E501 line too long (80 > 79 characters)

Comment last updated at 2022-05-02 11:17:53 UTC

[simnh]

Thanks for the approach, looks interesting to me! Conceptually I would start on the energy system class level before building the model, i.e.:

• telling the system it is a cellular one (as you did, but first on the energysystem class and not the model)
• build functionality to create the cells and telling each component (so the component gets an attribute such ascell = {"name": "cell1", "level"=0} in which cell it is located (also maybe implement a hierarchy with different levels starting by 0). For this, the grouping functionality can surely be used (similar as what you already did). Maybe it's also worth thinking about if there could be a cell class subclassing from the energy system. in this case we could simply build all models for all cells and then link them afterward.
• On the model level I would think about subclassing from the Model class creating a CellularModel (so we do not mess up the Model class with methods and attributes only required in the cellular case ;)
• figuring out a way to easily build the objective function as you did

We should discuss this at the meeting with @gnn and @p-snft :)...maybe we can take a session on Thursday or on Friday

[minhki95]

Thank you for your first remarks.
I will give it all a thought and see what the most convenient approach is for implementation.
I also discovered that there is already a PR existing from @lensum see below.
#756
Does anybody have any contact information for that user? I think an exchange would be very helpful as the idea described is similar and some progress in coding has already been made.

[lensum]

Hey @minhki95
really interesting work you're doing! I'm also currently looking into the cellular approach and would very much appreciate an exchange of ideas with you!

Concerning the weighted sum method: We (my colleagues with whom I've created the code and me) haven't been working on that feature for some time now. Primarily, because we weren't shure if the benefits pay off for all the changes we made. They were a bit more extensive, as we tried to implement more of a framework for multi-objective optimization techniques, rather than a single feature. As @p-snft pointed out in the PR-thread: in many cases you can simply sum the variable cost terms with the appropriate weights before solving. Is that maybe an option for you as well?

Based on the "framework" we've implemented I've also added a lexicographic approach in my private repo-clone but have not yet had the time to pick up where we left with the PR and transfer the changes to it. If there is interest, I would give it a higher priority.

In case you want to get in touch: Is there some way I can send you my contact details privately? I wouldn't want them to be publicly readable here. Unfortunately, I cannot participate in the oemof-meeting in two weeks.

[minhki95]

Please do so using this address: [email protected].
Thank you for getting in touch!

[lensum]

Hey @minhki95,
is this PR (and also the one at oemof-network) still active? As you can see in this PR, I'm also currently working on this functionality and @p-snft has the need for some additional kind of grouping, that is similar to cellular structures (if I understood it correctly). So if you still need this kind of functionality, we should maybe join forces and find a way to implement all our needs with minimal changes to the code basis.

[minhki95]

Hi @lensum,

thank you for reaching out. Yes, I am still working with it. But mainly I use the grouping for postprocessing. My focus has shifted to an analysis of the market interactions between the different cells under global optimization. But I would still be interested what functionalities you and @p-snft have intended and if this has any implications for the optimization.

Therefore I have dismissed the idea of the weighted sum as the choice of the weightings was too arbitrary and based on empiricism.

You can reach out to me on my personal mail adress as I have no direct affilition with RLI anymore.