Fix minimum up-/ downtime #1021

p-snft · 2023-11-22T21:23:30Z

For minimum_uptime and minimum_downtime time steps were counted. However, time steps might have different lengths. This can lead to inconsistencies.

Fixes #1017

p-snft · 2023-11-23T06:24:54Z

@AntonellaConsolinno, @gnn, @lensum : In a first step, I tried to simplify the constraint. I still need to adjust the summation index so that the old behaviour is reproduced.

src/oemof/solph/flows/_non_convex_flow_block.py

…downtime Fix/minimum uptime downtime

pep8speaks · 2023-11-24T14:39:14Z

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

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2023-12-07 09:14:55 UTC

p-snft · 2023-11-27T11:47:57Z

src/oemof/solph/flows/_non_convex_flow_block.py

-            if self._time_step_allows_flexibility(
-                t, m.flows[i, o].nonconvex.max_up_down, m.TIMESTEPS.at(-1)
-            ):


Removing this calls for a different handling of the first time steps. Maybe, we continue to not create the constraint for the first N time steps so that the first time of switching down can continue to be our marker.

Also: The old style was assuming cyclic time. I think we should leave that as an option.

or the first timesteps have to be fixed and afterwards implement only the constraints of the timesteps > uptime/downtime

Just to have this more graphic. The old implementation interpreted the minimum uptime or downtime to force the flow up or down in the beginning and in the end.

Old implementation:

Current implementation:

Thinking about this a bit longer, there is a bug.

pp2 = solph.components.Source( label="plant_min_up_constraints", outputs={ bel: solph.Flow( nominal_value=10, min=0.5, max=1.0, variable_costs=10, nonconvex=solph.NonConvex(minimum_uptime=2, minimum_downtime=4, initial_status=1), ) }, )

Results in the flow being forced active for four time steps. I think backwards compatibility wit this can be dropped, as its an obvious mistake.

The goal is only to force the up or down (depending on initial_status) only in the beginning. Or is there a reason, why it has to be forced to be up / down in the end?

In my opinion the second plot ("current implementation") is showing the correct behavor.

The "current implementation" in this branch does only force the status up/down in the beginning. However, it does so for longer than needed (third plot and #1021 (comment)).

I think, it would make sense to allow forcing the status up/down in the end of the optimisation horizon as an equivalent to the "balanced" storage. If the storage has minimum downsteps of 4, it can have 2 in the end plus 2 in the beginning. But this should just be an option. The old implementation (in v0.5.1 and before) really made no sense.

This allows to go back to the indexing we used before.

src/oemof/solph/_options.py

The old implementation lead to unwanted situations. E.g. a Flow with `initial_status=0` forcibly off for more time steps than `minimum_downtime` if the the `minimum_uptime` was bigger.

p-snft

I think it makes sense to first refactor the old code before extending it. So, here we go.

src/oemof/solph/_options.py

src/oemof/solph/flows/_non_convex_flow_block.py

This also means that NonConvex.max_up_down has to be deleted, as it's not meaningful for two series.

Initialising the sequence as non-empty allows for using it in e.g. `max(sequence(value)) == value`

tests/test_plumbing.py

The "fixed" test just tests if an error is risen on access. Saving the (not existing) result to a variable should avoid code quality bots from complaining.

I do not get why this does not fail in dev, but I am taking the freedom to alter it in this branch so that it does not cause problems.

The new formulation needs less constraints, so the constraint test needs to be adjusted.

I really do not get why this was not an issue before. (I know that Pyomo started "rounding" some time ago.)

p-snft · 2023-12-01T15:15:03Z

The classical mode with constant number of steps seems to work in the refactored version. However, the results when giving a series are not really intuitive (or wrong). I wrote a small script to investigate this:

from oemof import solph

def test_min_uptime():
    # create an energy system
    idx = solph.create_time_index(2024, number=24)
    es = solph.EnergySystem(timeindex=idx, infer_last_interval=False)

    source = solph.Bus(label="source", balanced=False)
    sink = solph.Bus(
        label="sink",
        inputs={
            source: solph.Flow(
                nominal_value=10,
                min=0.1,
                max=[
                    1.01, 1.02, 1.03, 1.04, 1.05, 1.06,
                    1.07, 1.08, 1.09, 1.10, 1.11, 1.12,
                    1.13, 1.14, 1.15, 1.16, 1.17, 1.18,
                    1.19, 1.20, 1.21, 1.22, 1.23, 1.24,
                ],
                variable_costs=[
                    0.06, 0.05, 0.04, -9, 0.02, 0.01,
                    0.07, 0.08, 0.09, 0.10, 0.11, -9,
                    0.13, 0.14, 0.15, -9, 0.17, 0.18,
                    0.24, 0.23, 0.22, -9, 0.20, 0.19,
                ],
                nonconvex=solph.NonConvex(
                    minimum_uptime=[
                        3, 3, 2, 3, 3, 3,
                        2, 2, 2, 2, 2, 2,
                        4, 4, 4, 4, 4, 4,
                        3, 3, 3, 3, 3, 3,
                    ],
                )
            ),
        },
        balanced=False,
    )

    es.add(source, sink)
    om = solph.Model(es)
    om.solve(solver="cbc", solve_kwargs={"tee": False})
    results = solph.processing.results(om)

    data = solph.views.node(results, source)
    print(list(data["sequences"][(source, sink), "flow"]))


if __name__ == "__main__":
    test_min_uptime()

Results in the following time series for the Flow:

0.0, 0.0, 0.0, 10.4, 1.0, 1.0, # I would expect the Flow to start one earlier to have just two steps on.
0.0, 0.0, 0.0, 0.0, 0.0, 11.2,
1.0, 1.0, 1.0, 11.6, 0.0, 0.0,
0.0, 0.0, 1.0, 12.2, 1.0, 0.0 # I would expect the Flow to start one later because the costs are less.

AntonellaGia · 2023-12-04T09:22:30Z

The classical mode with constant number of steps seems to work in the refactored version. However, the results when giving a series are not really intuitive (or wrong). I wrote a small script to investigate this:

from oemof import solph

def test_min_uptime():
    # create an energy system
    idx = solph.create_time_index(2024, number=24)
    es = solph.EnergySystem(timeindex=idx, infer_last_interval=False)

    source = solph.Bus(label="source", balanced=False)
    sink = solph.Bus(
        label="sink",
        inputs={
            source: solph.Flow(
                nominal_value=10,
                min=0.1,
                max=[
                    1.01, 1.02, 1.03, 1.04, 1.05, 1.06,
                    1.07, 1.08, 1.09, 1.10, 1.11, 1.12,
                    1.13, 1.14, 1.15, 1.16, 1.17, 1.18,
                    1.19, 1.20, 1.21, 1.22, 1.23, 1.24,
                ],
                variable_costs=[
                    0.06, 0.05, 0.04, -9, 0.02, 0.01,
                    0.07, 0.08, 0.09, 0.10, 0.11, -9,
                    0.13, 0.14, 0.15, -9, 0.17, 0.18,
                    0.24, 0.23, 0.22, -9, 0.20, 0.19,
                ],
                nonconvex=solph.NonConvex(
                    minimum_uptime=[
                        3, 3, 2, 3, 3, 3,
                        2, 2, 2, 2, 2, 2,
                        4, 4, 4, 4, 4, 4,
                        3, 3, 3, 3, 3, 3,
                    ],
                )
            ),
        },
        balanced=False,
    )

    es.add(source, sink)
    om = solph.Model(es)
    om.solve(solver="cbc", solve_kwargs={"tee": False})
    results = solph.processing.results(om)

    data = solph.views.node(results, source)
    print(list(data["sequences"][(source, sink), "flow"]))


if __name__ == "__main__":
    test_min_uptime()

Results in the following time series for the Flow:

0.0, 0.0, 0.0, 10.4, 1.0, 1.0, # I would expect the Flow to start one earlier to have just two steps on. -> The costs for the third timestep (0.04 is higher then for timesteps five and six together 0.02+0.01) this leads to start running at the fourth timestep
0.0, 0.0, 0.0, 0.0, 0.0, 11.2,
1.0, 1.0, 1.0, 11.6, 0.0, 0.0,
0.0, 0.0, 1.0, 12.2, 1.0, 0.0 # I would expect the Flow to start one later because the costs are less. -> I think there the loop has to go one step further for the last timestep
min(
t + m.flows[i, o].nonconvex.minimum_uptime[t],
len(m.TIMESTEPS),

src/oemof/solph/flows/_non_convex_flow_block.py

AntonellaGia · 2023-12-04T09:42:17Z

Checking the downtime also leads to iterate one timestep more

from oemof import solph

def test_min_downtime():
    # create an energy system
    idx = solph.create_time_index(2024, number=24)
    es = solph.EnergySystem(timeindex=idx, infer_last_interval=False)

    source = solph.Bus(label="source", balanced=False)
    sink = solph.Bus(
        label="sink",
        inputs={
            source: solph.Flow(
                nominal_value=10,
                min=0.1,
                max=[
                    1.01, 1.02, 1.03, 1.04, 1.05, 1.06,
                    1.07, 1.08, 1.09, 1.10, 1.11, 1.12,
                    1.13, 1.14, 1.15, 1.16, 1.17, 1.18,
                    1.19, 1.20, 1.21, 1.22, 1.23, 1.24,
                ],
                variable_costs=[
                    -0.06, -0.05, -0.04, 9, -0.02, -0.01,
                    -.07, -0.08, -0.09, 0.10, -0.11, 9,
                    -0.13, -0.14, -0.15, 9, -0.17, -0.18,
                    -0.24, -0.23, -0.22, 9, -0.20, -0.19,
                ],
                nonconvex=solph.NonConvex(
                    minimum_downtime=[
                        3, 3, 2, 3, 3, 3,
                        2, 2, 2, 2, 2, 2,
                        4, 4, 4, 4, 4, 4,
                        3, 3, 3, 3, 3, 3,
                    ],
                    initial_status=1,
              )
            ),
        },
        balanced=False,
    )

    es.add(source, sink)
    om = solph.Model(es)
    om.solve(solver="cbc", solve_kwargs={"tee": False})
    results = solph.processing.results(om)

    data = solph.views.node(results, source)
    print(list(data["sequences"][(source, sink), "flow"]))


if __name__ == "__main__":
    test_min_uptime()

Results in the following time series for the Flow old version:

[10.1, 10.2, 10.3, 0.0, 0.0, 0.0, 10.7, 10.8, 10.9, 1.0, 11.1, 0.0, 0.0, 0.0, 0.0, 0.0, 11.7, 11.8, 11.9, 12.0, 12.1, 0.0, 0.0, 12.4, nan] # last downtime of 3 is not used
Results after adaption:
0.1, 10.2, 10.3, 0.0, 0.0, 0.0, 10.7, 10.8, 10.9, 1.0, 11.1, 0.0, 0.0, 0.0, 0.0, 0.0, 11.7, 11.8, 11.9, 12.0, 12.1, 0.0, 0.0, 0.0, nan]

src/oemof/solph/flows/_non_convex_flow_block.py

p-snft · 2023-12-05T20:13:37Z

I keep forgetting that range(items[-1]) will count to items[-1]-1. Thanks.

…solph into fix/minimum-uptime-downtime

p-snft · 2023-12-06T15:28:59Z

I think we should merge this already and prepare the calculation of the required steps for a given length in hours to a second PR.

Note: Technically speaking, this is not API stable. However, I would consider the old behavour a bug.

AntonellaGia

I proved only the code without investment. Maybe someone else can check this. The constraints itself I approve

jokochems

Seems plausible to me, thank you @p-snft and @AntonellaConsolinno. Admittedly, I only quickly scrolled through the code, but I like the additions also in terms of tests.

Draft simplified min_downtime_rule

ac8b702

p-snft linked an issue Nov 22, 2023 that may be closed by this pull request

Minimum uptime/ downtime #1017

Open

p-snft assigned p-snft and gnn and unassigned gnn and p-snft Nov 22, 2023

jokochems reviewed Nov 24, 2023

View reviewed changes

src/oemof/solph/flows/_non_convex_flow_block.py Outdated Show resolved Hide resolved

AntonellaGia and others added 3 commits November 24, 2023 12:36

limit t for constraint and update uptime_rule

2f09a60

constraint-test

bb1ee0c

Merge pull request #1024 from AntonellaConsolinno/fix/minimum-uptime-…

c987b98

…downtime Fix/minimum uptime downtime

p-snft added 2 commits November 24, 2023 16:17

Adhere to Black

c2175a9

Remove unused code

b12a24f

p-snft commented Nov 27, 2023

View reviewed changes

p-snft added 2 commits November 27, 2023 14:37

Fix activity status in initial steps

b9aa489

This allows to go back to the indexing we used before.

Adhere to Black

da8f826

AntonellaGia reviewed Nov 28, 2023

View reviewed changes

src/oemof/solph/_options.py Outdated Show resolved Hide resolved

Set first flexible time step of NonConvexFlow based on initial status

70c3b61

The old implementation lead to unwanted situations. E.g. a Flow with `initial_status=0` forcibly off for more time steps than `minimum_downtime` if the the `minimum_uptime` was bigger.

p-snft commented Nov 28, 2023

View reviewed changes

src/oemof/solph/_options.py Outdated Show resolved Hide resolved

src/oemof/solph/flows/_non_convex_flow_block.py Show resolved Hide resolved

src/oemof/solph/flows/_non_convex_flow_block.py Show resolved Hide resolved

p-snft and others added 8 commits November 29, 2023 20:21

Deprecate NonConvex.max_up_down

b616c52

Fix invalid initial status in constraint_test

00e9825

Explain need for braching in _min_uptime_rule

111f1e1

Add NonConvex up-/ downtime fix to WhatsNew

fe05c56

Let minimum_uptime and minimum_downtime be series

7f21174

This also means that NonConvex.max_up_down has to be deleted, as it's not meaningful for two series.

Remove unused import

d72a590

Let len(sequence(0)) == 1

9312c7c

Initialising the sequence as non-empty allows for using it in e.g. `max(sequence(value)) == value`

Adhere to Black

1a93871

github-advanced-security bot found potential problems Nov 30, 2023

View reviewed changes

tests/test_plumbing.py Fixed Show fixed Hide fixed

AntonellaGia and others added 7 commits December 1, 2023 06:22

Update documenation

2b30979

Remove trailing whitespace

951ebbb

Workaround useless statement message

42a2b80

The "fixed" test just tests if an error is risen on access. Saving the (not existing) result to a variable should avoid code quality bots from complaining.

Fix storage investment test

67511b1

I do not get why this does not fail in dev, but I am taking the freedom to alter it in this branch so that it does not cause problems.

Adjust min_max_runtime test lp files

64f67e7

The new formulation needs less constraints, so the constraint test needs to be adjusted.

Replace "0.0" by "0" in dsm test lp file

22abd38

I really do not get why this was not an issue before. (I know that Pyomo started "rounding" some time ago.)

Merge branch 'dev' into fix/minimum-uptime-downtime

aedfcbf

AntonellaGia added 2 commits December 4, 2023 10:22

iterate one more step uptime last timestep

76989a0

iterate one more step downtime last timestep

44639b6

AntonellaGia reviewed Dec 4, 2023

View reviewed changes

src/oemof/solph/flows/_non_convex_flow_block.py Show resolved Hide resolved

AntonellaGia reviewed Dec 4, 2023

View reviewed changes

src/oemof/solph/flows/_non_convex_flow_block.py Show resolved Hide resolved

p-snft mentioned this pull request Dec 5, 2023

Remove duplicated discounting #1028

Merged

p-snft and others added 3 commits December 6, 2023 11:07

Merge branch 'dev' into fix/minimum-uptime-downtime

8d20184

Add last time step to Multi-period min/max constraint test

d5fff12

Merge branch 'fix/minimum-uptime-downtime' of github.com:oemof/oemof-…

85f58f9

…solph into fix/minimum-uptime-downtime

p-snft marked this pull request as ready for review December 6, 2023 15:29

Add sequence for up/downtime to Whatsnew

88ccea7

p-snft requested review from jokochems and AntonellaGia December 7, 2023 09:37

AntonellaGia approved these changes Dec 7, 2023

View reviewed changes

jokochems approved these changes Dec 7, 2023

View reviewed changes

p-snft removed a link to an issue Dec 7, 2023

Minimum uptime/ downtime #1017

Open

p-snft merged commit b6a64b9 into dev Dec 7, 2023

p-snft mentioned this pull request Dec 7, 2023

Minimum uptime/ downtime #1017

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix minimum up-/ downtime #1021

Fix minimum up-/ downtime #1021

p-snft commented Nov 22, 2023

p-snft commented Nov 23, 2023

pep8speaks commented Nov 24, 2023 •

edited

Loading

p-snft Nov 27, 2023 •

edited

Loading

AntonellaGia Nov 27, 2023

p-snft Nov 27, 2023

AntonellaGia Nov 28, 2023 •

edited

Loading

p-snft Nov 28, 2023

p-snft left a comment

p-snft commented Dec 1, 2023 •

edited

Loading

AntonellaGia commented Dec 4, 2023

AntonellaGia commented Dec 4, 2023

p-snft commented Dec 5, 2023

p-snft commented Dec 6, 2023 •

edited

Loading

AntonellaGia left a comment

jokochems left a comment

Fix minimum up-/ downtime #1021

Fix minimum up-/ downtime #1021

Conversation

p-snft commented Nov 22, 2023

p-snft commented Nov 23, 2023

pep8speaks commented Nov 24, 2023 • edited Loading

Comment last updated at 2023-12-07 09:14:55 UTC

p-snft Nov 27, 2023 • edited Loading

Choose a reason for hiding this comment

AntonellaGia Nov 27, 2023

Choose a reason for hiding this comment

p-snft Nov 27, 2023

Choose a reason for hiding this comment

AntonellaGia Nov 28, 2023 • edited Loading

Choose a reason for hiding this comment

p-snft Nov 28, 2023

Choose a reason for hiding this comment

p-snft left a comment

Choose a reason for hiding this comment

p-snft commented Dec 1, 2023 • edited Loading

AntonellaGia commented Dec 4, 2023

AntonellaGia commented Dec 4, 2023

p-snft commented Dec 5, 2023

p-snft commented Dec 6, 2023 • edited Loading

AntonellaGia left a comment

Choose a reason for hiding this comment

jokochems left a comment

Choose a reason for hiding this comment

pep8speaks commented Nov 24, 2023 •

edited

Loading

p-snft Nov 27, 2023 •

edited

Loading

AntonellaGia Nov 28, 2023 •

edited

Loading

p-snft commented Dec 1, 2023 •

edited

Loading

p-snft commented Dec 6, 2023 •

edited

Loading