Features/Multiobjective Optimization #756

lensum · 2021-03-26T12:31:27Z

Hey there,

we have integrated a feature to solve an oemof-model using a multi-objective approach. For now only a weighted objective function approach is implemented, but other multi-objective algorithms could be integrated as well. The implementation is similar to that of the investment and nonconvex methods in using an additional attribute of Flow instances with an associated class in options.

Overview:

To solve a multi-objective optimisation in oemof, these new elements are introduced:

new class MultiObjectiveModel in module models
- with new _add_objective()
- with new solve()
new class MultiObjectiveFlow in module blocks
new class MultiObjective with a comfort class Objective in module options
new function _multiobjective_grouping and corresponding grouping in module groupings

The main idea is that flows can have different costs for different objectives by setting the multiobjective attribute of the Flow. This consists of key-value-pairs with the name for the partial objective function and an instance of the Objective nested class with the corresponding parameters.

Example: Adding a flow with two different costs for ecological and financial objectives:

import oemof.solph as solph
from oemof.solph.options import MultiObjective as mo

# create and add electrical source with two different prices
el_source = solph.Source(
        label='el_source',
        outputs={el_bus: solph.Flow(multiobjective=mo(
                ecological=mo.Objective(
                        variable_costs=15),
                financial=mo.Objective(
                        variable_costs=10)))})
energy_system.add(el_source_fix)

The implementation is therefore similar to the investment- and nonconvex-methods and extends the standard solph.GROUPINGS to aggregate all objectives with the same objective function handle.

The solve() function currently differentiates between single-objective and multi-objective optimization through the keyword argument optimization_type. Further attributes then depend on the chosen type, e.g. objective_weights.

Example: creating a mulitobjective Model and solving it with a weighted objective function:

# create a pyomo optimization problem
optimisation_model = solph.MultiObjectiveModel(energy_system)

# solve problem using glpk
solver_results = optimisation_model.solve(
        solver='glpk',
        optimization_type='weighted',
        objective_weights={'ecological': 0.4,
                            'financial': 0.5},)

As written above: Currently only weighted objective functions are implemented, but other multi-objective algorithms can be integrated in the future as well.

Insights:

Some further technical insights:

class MultiObjectiveModel
- function _add_objective() only collects objective functions and does not build objective-attribute of model instance
  - this faciliates solving the same model instance with e.g. different weightings or even different objectives
  - adds default handle '_standard' for backwards compability
  - not previously collected objectives - e.g. from invest or normal variable_costs-attributes - are added to '_standard'-objective
- the objective function is only build when calling solve() due to there being different attribute sets etc. for each type of optimization
- the weighted sum approach currently uses the given weights directly without considerations for normalization or possible numeric problems
class MultiObjectiveFlow
- adds no new constraints
- uses same calculation for objectives as Flow split into different objective functions
nested class Objective in class MultiObjective
- currently used only to faciliate setting parameters
- could possibly be extended to include investment parameters for different objectives
the additional grouping works the same as that for nonconvex or investment flows by checking the multiobjective attribute

Questions:

We chose to create a new class MultiObjectiveModel for this feature, but also discussed integrating it into the Model class directly. Our reasoning was that our approach would not be API-breaking and therefore preferable. We also ensured, however, that the behaviour of the MultiObjectiveModel class defaults to that of the Model class. Which implementation would you prefer?

Best regards,

Contributors:
west-a, esske, lensum, matvanbeek, matnpy

A little heads up:
This contribution is still work in progress. The code performs as expected, but we do not fulfill your guidelines on Pull-Requests yet. E.g.:

We have not yet checked if the tests run with tox (we worked on it with pytest)
The documentation needs updating
Changes must still be mentioned in CHANGELOG.rst
We did not yet add our names to AUTHORS.rst

…siert

… modules

pep8speaks · 2021-03-26T12:31:35Z

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

In the file src/oemof/solph/models.py:

Line 604:9: E303 too many blank lines (2)
Line 648:10: E225 missing whitespace around operator
Line 679:55: E251 unexpected spaces around keyword / parameter equals
Line 679:57: E251 unexpected spaces around keyword / parameter equals
Line 684:49: E225 missing whitespace around operator

Comment last updated at 2021-07-08 14:07:12 UTC

esske · 2021-03-26T12:42:02Z

@lensum

simnh · 2021-03-26T13:42:07Z

src/oemof/solph/models.py

+    def _add_parent_block_sets(self):
+        """"""
+        # set with all nodes
+        self.NODES = po.Set(initialize=[n for n in self.es.nodes])
+
+        # pyomo set for timesteps of optimization problem
+        self.TIMESTEPS = po.Set(
+            initialize=range(len(self.es.timeindex)), ordered=True
+        )
+
+        # previous timesteps
+        previous_timesteps = [x - 1 for x in self.TIMESTEPS]
+        previous_timesteps[0] = self.TIMESTEPS.last()
+
+        self.previous_timesteps = dict(zip(self.TIMESTEPS, previous_timesteps))
+
+        # pyomo set for all flows in the energy system graph
+        self.FLOWS = po.Set(
+            initialize=self.flows.keys(), ordered=True, dimen=2
+        )
+
+        self.BIDIRECTIONAL_FLOWS = po.Set(
+            initialize=[
+                k
+                for (k, v) in self.flows.items()
+                if hasattr(v, "bidirectional")
+            ],
+            ordered=True,
+            dimen=2,
+            within=self.FLOWS,
+        )
+
+        self.UNIDIRECTIONAL_FLOWS = po.Set(
+            initialize=[
+                k
+                for (k, v) in self.flows.items()
+                if not hasattr(v, "bidirectional")
+            ],
+            ordered=True,
+            dimen=2,
+            within=self.FLOWS,
+        )
+
+    def _add_parent_block_variables(self):
+        """"""
+
+        self.flow = po.Var(self.FLOWS, self.TIMESTEPS, within=po.Reals)
+
+        for (o, i) in self.FLOWS:
+            if self.flows[o, i].nominal_value is not None:
+                if self.flows[o, i].fix[self.TIMESTEPS[1]] is not None:
+                    for t in self.TIMESTEPS:
+                        self.flow[o, i, t].value = (
+                            self.flows[o, i].fix[t]
+                            * self.flows[o, i].nominal_value
+                        )
+                        self.flow[o, i, t].fix()
+                else:
+                    for t in self.TIMESTEPS:
+                        self.flow[o, i, t].setub(
+                            self.flows[o, i].max[t]
+                            * self.flows[o, i].nominal_value
+                        )
+
+                    if not self.flows[o, i].nonconvex:
+                        for t in self.TIMESTEPS:
+                            self.flow[o, i, t].setlb(
+                                self.flows[o, i].min[t]
+                                * self.flows[o, i].nominal_value
+                            )
+                    elif (o, i) in self.UNIDIRECTIONAL_FLOWS:
+                        for t in self.TIMESTEPS:
+                            self.flow[o, i, t].setlb(0)
+            else:
+                if (o, i) in self.UNIDIRECTIONAL_FLOWS:
+                    for t in self.TIMESTEPS:
+                        self.flow[o, i, t].setlb(0)


Did you actually change something compared to the BaseModel class? If not, we would not need this code, because the methods are provided by the BaseClass, aren't they? (long time doing sub-classing coding in Python)

It is an addition compared to the BaseModel class, yes, but not compared to the Model class. So I think the MultiObjectiveModel class should inherit from the Model class instead of the BaseModel class to reduce code duplication.

Hi, quite a nice feature and a bit related to the pending multiperiod feature #750.
It seems, the only difference here is amending the CONSTRAINT_GROUPS list by block.MultiObjectiveFlow. So letting the class inherit from the Model class seems like a good idea and would save you redefining the methods already given there.

The dependency is now fixed, together with a few linting errors. Codacy throws an error because of an import statement which it should ignore. I don't really know what to do there, suggestions are highly appreciated.
Other than that, all pipelines are passed.

Altering the AUTHORS.rst and CHANGELOG.rst created a merge conflict, so I reverted that commit. I will try to alter those files one by one, to see whether only one of them creates a merge conflict and then go on from there.

…reduce code duplication

Dies reverted den Commit ce21ef0.

* Adapted test_multiobjective/test_multiobjective.py to adhere to pep8 regarding linebreaks around operators * removed unnecessary check for solver status

Removed unneeded imports and variables

* Corrected import order in tests * Added missing documentation in Flow class * Changed module docstrings for tests

lensum · 2021-06-10T07:22:57Z

Hey there,
I think this PR is almost ready, so I removed the "WIP" in the title. A maintainer would need to approve the running workflows. Codacy does not like the import statement for the new MultiObjectiveFlow, I think this also requires action from a maintainer. Due to bad style from our site, we cannot change the CHANGELOG.rst or the AUTHORS.rst without creating a merge conflict. Is there anything we need to do additionally?

jokochems · 2021-06-11T06:50:17Z

Hi @lensum,

I'm sorry, I'm not a maintainer myself. But what you can / should do beforehand is merge the current version of the oemof/dev branch into your project and resolve the merge conflicts. If you are a PyCharm user, this is pretty straightforward and you can just "click" together a combined version in the merge view. For the network/flow.py file, it seems that you are just lacking the latest additions.

…estions. Merge conflict resulted from merging upstream repository into fork.

lensum · 2021-06-14T14:24:13Z

Thanks @jokochems, just did that. Seems to me, the only thing left is the approval of a maintainer 👍

p-snft · 2021-06-16T08:35:01Z

Thanks for your effort.

I do understand you approach, but to represent the current feature level, other choices would be easier to maintain. In the end, it comes down to one sentence in your introduction:

other multi-objective algorithms could be integrated as well.

If you are going to implement something like this, it makes sense to explicitly add different types of cost. If this is not the case, I would opt for a solution that just adds the weighted cost:

import oemof.solph as solph

weights = {
    "ecological" 0.4,
    "financial": 0.6,
}

# create and add electrical source with two different prices
el_source = solph.Source(
        label='el_source',
        outputs={el_bus: solph.Flow(
                variable_costs=(weights["ecological"] *  15
                                + weights["financial"] * 10))})
energy_system.add(el_source_fix)

lensum · 2021-06-22T06:31:14Z

Thanks for your effort.

I do understand you approach, but to represent the current feature level, other choices would be easier to maintain. In the end, it comes down to one sentence in your introduction:

other multi-objective algorithms could be integrated as well.

If you are going to implement something like this, it makes sense to explicitly add different types of cost. If this is not the case, I would opt for a solution that just adds the weighted cost:
import oemof.solph as solph

weights = {
    "ecological" 0.4,
    "financial": 0.6,
}

# create and add electrical source with two different prices
el_source = solph.Source(
        label='el_source',
        outputs={el_bus: solph.Flow(
                variable_costs=(weights["ecological"] *  15
                                + weights["financial"] * 10))})
energy_system.add(el_source_fix)

Thank you for the reply, @p-snft. True, the above method would also work. Then I guess the sensible thing to do is to put this MR on hold until we've added another method?

Corrected wrong parenthesis in MultiObjective.Objective class

Added pareto()-function in MultiObjectiveModel to automatically calculate pareto frontiert based on weighted sums of objectives. Calculated weight combinations can be used to find optimal multi-objective solution.

jokochems · 2022-11-10T13:44:20Z

There hasn't been any activity on this pull request in quite a while. Nonetheless, I think, it would be a good improvement to include after the release of v0.5.0 resp. v0.5.1.

lensum · 2022-11-15T06:08:54Z

Thank you @jokochems for the reminder! I also think it would be best to wait for the release of v.0.5.0 and maybe include it in the release of v.0.5.1. However, so far the development has been a group effort (and I would like to keep it that way), so it might be difficult to keep up with the schedule for the release of v.0.5.1. We'll try!

lensum and others added 9 commits March 25, 2021 11:46

Update __init__.py

24295b4

Create multiobjective_flow.py

6cff1c7

Update groupings.py

bfe602e

Update models.py

0b2147b

Update flow.py

7f62a16

Update options.py

22fe531

test_model.py, test_model_solve.py und test_multiobjective.py aktuali…

5cee604

…siert

updated __init__.py in solph and blocks to contain new multiobjective…

59fdb49

… modules

fixed missing package import in models.py

c3dfdcf

simnh reviewed Mar 26, 2021

View reviewed changes

lensum and others added 12 commits April 26, 2021 12:46

dependency of MultiObjectiveModel changed from BaseModel to Model to …

794b83d

…reduce code duplication

added authors and changelog

ce21ef0

enhanced PEP8 conformity

ff1073d

Revert "added authors and changelog"

54e6816

Dies reverted den Commit ce21ef0.

corrected linting errors

5fb6f02

further linting errors removed

18b4a3d

Fixed linting error in test script

9606708

* Adapted test_multiobjective/test_multiobjective.py to adhere to pep8 regarding linebreaks around operators * removed unnecessary check for solver status

Fixed further oversight in style

4c7e799

Removed unneeded imports and variables

Several fixes to import order/documentation

1fd6421

* Corrected import order in tests * Added missing documentation in Flow class * Changed module docstrings for tests

Fixed indentation typo

a912107

Corrected import sorting

241530e

fixed import order

38891c8

lensum changed the title ~~WIP: Features/Multiobjective Optimization~~ Features/Multiobjective Optimization Jun 10, 2021

Resolved merge conflict in network/flow.py by incorporating both sugg…

e2ac551

…estions. Merge conflict resulted from merging upstream repository into fork.

west-a added 2 commits June 30, 2021 11:31

Fixed wrong parenthesis

95da9e5

Corrected wrong parenthesis in MultiObjective.Objective class

WIP: added function to find pareto frontier

17ead41

Added pareto()-function in MultiObjectiveModel to automatically calculate pareto frontiert based on weighted sums of objectives. Calculated weight combinations can be used to find optimal multi-objective solution.

p-snft marked this pull request as draft December 1, 2021 13:15

minhki95 mentioned this pull request May 5, 2022

Feature/objective function weighted sum #840

Draft

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Features/Multiobjective Optimization #756

Features/Multiobjective Optimization #756

lensum commented Mar 26, 2021

pep8speaks commented Mar 26, 2021 •

edited

Loading

esske commented Mar 26, 2021

simnh Mar 26, 2021

lensum Mar 31, 2021

jokochems Apr 10, 2021

lensum May 3, 2021

lensum commented Jun 10, 2021

jokochems commented Jun 11, 2021

lensum commented Jun 14, 2021

p-snft commented Jun 16, 2021

lensum commented Jun 22, 2021

jokochems commented Nov 10, 2022

lensum commented Nov 15, 2022

Features/Multiobjective Optimization #756

Are you sure you want to change the base?

Features/Multiobjective Optimization #756

Conversation

lensum commented Mar 26, 2021

pep8speaks commented Mar 26, 2021 • edited Loading

Comment last updated at 2021-07-08 14:07:12 UTC

esske commented Mar 26, 2021

simnh Mar 26, 2021

Choose a reason for hiding this comment

lensum Mar 31, 2021

Choose a reason for hiding this comment

jokochems Apr 10, 2021

Choose a reason for hiding this comment

lensum May 3, 2021

Choose a reason for hiding this comment

lensum commented Jun 10, 2021

jokochems commented Jun 11, 2021

lensum commented Jun 14, 2021

p-snft commented Jun 16, 2021

lensum commented Jun 22, 2021

jokochems commented Nov 10, 2022

lensum commented Nov 15, 2022

pep8speaks commented Mar 26, 2021 •

edited

Loading