Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop trimming the planning window in response to price availability #538

Merged
merged 5 commits into from Dec 2, 2022

Conversation

Flix6x
Copy link
Contributor

@Flix6x Flix6x commented Nov 24, 2022

My initial reason to create this PR was to prevent the scheduler from emptying the storage at the end of the scheduling horizon. We now prevent this by making an assumption about the future beyond the part of the scheduling horizon with available prices. Specifically, we use the most naive forecasting (forward filling the last known price).

Note that in case of a negative price, this would still result in emptying the battery; but e.g. switching to naive forecasting with a seasonal periodicity of 1 day or 1 week would give inconsistent results, because they will then depend on how long a price period has been loaded in the price BeliefsDataFrame.

Then I encountered a second reason for this PR. By stopping to trim the planning window in response to price availability, another bug is resolved as well. Namely, for cases when SoC targets occur outside of the available price window. The two choices I saw here were to either trim the SoC targets or to not trim the planning window. Trimming the SoC targets would lead to a schedule that might in the end lead violating the user's constraints, so that's not a good option. I'd rather make a simplistic assumption about future prices in order to not have to trim the planning window.

…ing horizon, using naive forecasting (forward filling the last known price); note that in case of a negative price, this would still result in emptying the battery; switching to naive forecasting with a seasonal periodicity of 1 day or 1 week would give inconsistent results, because they will then depend on how long a perice period has been loaded in the price bdf.

Signed-off-by: F.N. Claessen <felix@seita.nl>
@Flix6x Flix6x requested a review from nhoening November 24, 2022 10:11
@Flix6x Flix6x self-assigned this Nov 24, 2022
@coveralls
Copy link
Collaborator

coveralls commented Nov 24, 2022

Pull Request Test Coverage Report for Build 3600092930

  • 4 of 5 (80.0%) changed or added relevant lines in 1 file are covered.
  • 4 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.02%) to 64.96%

Changes Missing Coverage Covered Lines Changed/Added Lines %
flexmeasures/data/models/planning/utils.py 4 5 80.0%
Files with Coverage Reduction New Missed Lines %
flexmeasures/data/models/planning/utils.py 4 82.58%
Totals Coverage Status
Change from base Build 3596441907: -0.02%
Covered Lines: 6587
Relevant Lines: 9521

💛 - Coveralls

Copy link
Contributor

@nhoening nhoening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we create data somewhat artificially, we should also print a warning, similar to the other case.

…g window

Signed-off-by: F.N. Claessen <felix@seita.nl>
@Flix6x Flix6x requested a review from nhoening November 24, 2022 22:32
Copy link
Contributor

@nhoening nhoening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we can extend the docstring of get_prices to include the behaviour of using the first and last valid values to fill in larger windows. That might be unexpected for developers who use it.

Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
@Flix6x
Copy link
Contributor Author

Flix6x commented Dec 2, 2022

After reconsidering, I now think I misrepresented this PR. It definitely still solves that bug, but it doesn't prevent the scheduler from emptying the storage at the end of the scheduling horizon. I wrote the changelog entry to reflect that.

So what happened? I initially wrote this for a simulation project, in which I noticed the storage emptying at the end of the simulation. Why? No prices were loaded beyond the end of the simulation time window, so the last planning window was trimmed in response to price availability. And the storage empties at the end of the schedule. Now that the planning window is no longer trimmed, the storage still emptied, but only outside of the simulation window. I misinterpreted that., and hadn't taken the time to think it through.

Actually, many schedules end with emptying the storage, unless e.g. a target SoC has been set that constrains otherwise (or prices are negative, or there just isn't enough time to completely empty). This is why we typically execute the schedule only partially, and request a new schedule well before the end of the current schedule.

The storage empties because it earns money to do so, when prices are positive. When prices are negative, it fills up instead. So my second initial comment was also wrong. I've crossed out those parts.

…-at-scheduling-horizon

# Conflicts:
#	documentation/changelog.rst
@Flix6x Flix6x changed the title Prevent scheduler from emptying the storage at the end of the scheduling horizon Stop trimming the planning window in response to price availability Dec 2, 2022
@Flix6x Flix6x requested a review from nhoening December 2, 2022 08:28
@nhoening
Copy link
Contributor

nhoening commented Dec 2, 2022

Maybe an idea to make schedules more realistic is to

  • make them longer
  • add a final setpoint in the middle of capacity
  • or alternatively, add a constraint that the storage should end up in a non-empty range, e.g. 20-80 as we already do for the V2G work. For some others, this could be 35-65, just to stop unrealistic local-peak outcomes.

@Flix6x Flix6x merged commit 8affa7c into main Dec 2, 2022
@Flix6x Flix6x deleted the prevent-storage-drain-at-scheduling-horizon branch December 2, 2022 09:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Scheduling
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants