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
Conversation
…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>
Pull Request Test Coverage Report for Build 3600092930
💛 - Coveralls |
There was a problem hiding this 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>
There was a problem hiding this 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>
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
Maybe an idea to make schedules more realistic is to
|
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 bymaking 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.