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
Issue 273 add roundtrip efficiency to scheduler #291
Issue 273 add roundtrip efficiency to scheduler #291
Conversation
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
…nsor_data Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
… script Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
…ief, too" This reverts commit fb58ec7.
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
…scale prices Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
…pplication of round-trip efficiency as price scalars and modeling device flows in more detail Signed-off-by: F.N. Claessen <felix@seita.nl>
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.
Looks pretty good, besides one potential error and some documentation I'd like.
And one fundamental question: It seems we are going from one power
variable to ems_power
, device_power_down
and device_power_up
. Does this mean that in principle (although it is usually isn't optimal) we could charge and discharge at the same time?
Also, I have some notes which don't necessarily block this PR, so you could either address them, or we make a new ticket:
For full understanding, I wanted to see how the battery and charging stations differ. I had a tough time really seeing how that is, as battery.py and charging_station.py seem to share a large amount of code.
My assumption: They both schedule only one sensor (one for a battery, one for a charging station) against SOC targets for lowest costs. The "EMS" is not being optimized, but it actually is the environment of the 1 device (e.g. the grid).
Is that correct?
The comments are sometimes talking about "devices" (plural) so I'm unsure.
A few smaller questions, maybe addressable in this PR (with a comment or so) but maybe rather as tickets:
- What is the difference in treatment between battery and charging station? I compared the code for a few minutes, but I couldn't tell the major difference. Their docstring are also almost identical.
- Can we formally distinguish (check) that we treat a sensor/asset of correct type before we schedule?
- If the code is 75% (or so) identical, there might be an idea for future refactoring to note here.
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Signed-off-by: F.N. Claessen <felix@seita.nl>
Correct. At first I added the constraint
Our generic device scheduler (
The differences are few, actually. Perhaps they have been dissipating as development progressed. I think at this point it's only in the min/max state of charge (which is assumed to be a known sensor property for a battery, but not so for a Charge Point, because it depends on the connected EV).
Good idea. I made a card for project 6.
Refactoring is a good idea. I added a card to project 6. |
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.
Approved.
I feel that some comments you made during our discussion in this PR are worthwhile.
This one could be helpful in the solvers' docstring:
This generic device scheduler ( is able to handle an EMS with multiple devices, with constraints on the EMS level and on the device level, and market commitment on the EMS level. A typical example is a house with many devices.
The following one seems like a crucial list of assumptions we rely on - maybe in a comment:
(when discussing why we not make sure that charging and discharging cannot happen at the same time)
Given efficiencies between 0 than 1 and given convex commitment prices, I believe we can go without these constraints.
Are convex commitment prices a sure thing?
Signed-off-by: F.N. Claessen <felix@seita.nl>
…undtrip_efficiency_to_scheduler Signed-off-by: F.N. Claessen <felix@seita.nl> # Conflicts: # flexmeasures/api/__init__.py # flexmeasures/api/dev/tests/test_sensor_data.py # flexmeasures/data/models/time_series.py # flexmeasures/data/scripts/data_gen.py # flexmeasures/data/tests/test_queries.py # flexmeasures/data/utils.py
This PR rewrites our generic device scheduler to:
Furthermore, it allows round-trip efficiency to be communicated as a new optional field when POSTing UDI Events, with efficiency losses being assigned equally to charging and discharging.
Closes #273.
NB In a premature state, this PR applied round-trip efficiency by scaling charging and discharging prices accordingly. However, this approach is limited to use cases with a single device per EMS. With tariffs modeled as a commitment to zero prosumption, for a single-device EMS, the up price is equal to the consumption price (charging) and the down price is equal to the feed-in price (discharging).