Demand Response / Flexibility in Loads

[DEUCE1957]

Attempt to extend Redispatching by enabling Environment's to have flexible loads. See "getting_started" / "13_Demand?Response.ipynb" for example use. Related to issue #623

Currently working:
Able to define "flexibility" actions (env.action_space({"flexibility":[("load_0_0", 0.1]}) with correct print string for BaseAction
Able to load flexible load attributes from "flex_loads_charac.csv"
"InvalidFlexibility" error if flexibility exceeds size of load
Observable change in load after executing flexibility action in environment
Integration with redispatch routine (flexibility and redispatch are solved together in one optim. problem)
Observable change in actual/target flexibility after executing flexibility action in environment
Automated tests

Open Challenges/Issues:

How should we define the max load / load size? (currently is max of all chronix2grid load profiles in all of the chronics)

Progress

Actual/Target Flexibility in BaseObservation
Flexibility in BaseAction / PlayableAction
Flexibility in GridObject
Flexibility in SerializableActionSpace.sample()

Conventions:
Positive flexibility: Reduce consumption (less demand in the grid)
Negative flexibility: Increase consumption (more demand in the grid)
target_flex: Sum of all flexibility at a load
actual_flex: Sum of all physically feasible flexibility at a load (determined by Environment)

[BDonnot]

Hello,

I am not entirely sure about the design of this function here.

I did review some of the code, and in doing so I found surprising that the "flexibility" can also be positive. In practice this is not possible: you cannot force people to consume more.
Through the (day ahead) market, you can incentivize them to consume more or less through the price (and especially the negative prices observed more and more frequently). This is mainly done in the "day ahead market" (in EU at least) and so would be, I suppose, be input of grid2op data.

What is possible (DSO and TSO side, still in Europe) is to disconnect some loads to preserve the balancing of the grid, based on the frequency of the grid for example (this has been done in 2006 for example).
In this (exceptional) case, some part of the "area" that need to be cut are simply separated from the grid (disconnected from the TSO or DSO trafo).
This would be, I think, better modeled in grid2op by giving a "ratio" of the load that needs to be "removed" from the grid, instead of giving directly a number of MW.

Because, I believe, that giving a certain amount of MW would be problematic. For example, if a load would consume 13MW, but the agent ask to decrease it's load by 14MW, what happens ? It now injects 1MW in the grid ? This is unclear and might be totally unrealistic :-/

Also, I understood reading the code, flexibility is only for active demand. However, when some consumers are disconnected from the grid, their "reactive consumption" is also removed from the grid, not just their active consumption. It might be really hard to "synch" such property with the current implementation (giving explicit target in MW for active load). If the "ratio" model would be applied this would be (at least on a first test, easier to implement (apply same ratio for both active and reactive)

What do you think about that ?

Best

Benjamin

[BDonnot]

Another "error" not linked with my previous comment is that you probably forgot to include the necessary files for the load_flexibility in GitHub for the rte_case5_flexibility grid.

And this might be why CI is not working.

Also, I pulled your code and renamed "flexibility" to "load_flexibility" pretty much everywhere.

Best

Benjamin

[DEUCE1957]

Hi @BDonnot , thank you for taking the time to look through the PR request.

Regarding the ability to increase the load, this is only possible if the allowed ramping is non-zero. I tried to take the most general definition of flexibility, then it is up to the environment definition what is allowed or not allowed. Personally I have only used it to decrease load, but their might be scenarios where the opposite might be wanted or allowed.

Note however that since redispatch and flexibility persist after the agent asks for it (via target_redispatch and target_flexibility) that allowing for flexibility 'increases' can let the agent partially 'undo' a previous reduction (e.g. we can go from -8MW consumption to -6MW consumption (less load used) but then back up to -7MW consumption (still reduced, but increased relative to the -6MW)).

The case for using it to represent load shedding at higher voltages can be reflected with a discretized action space, which is how I did it previously in the MV case.

Regarding:
"Because, I believe, that giving a certain amount of MW would be problematic. For example, if a load would consume 13MW, but the agent ask to decrease it's load by 14MW, what happens ? It now injects 1MW in the grid ? This is unclear and might be totally unrealistic :-/"
That is not the intended behaviour, I implemented it so that the load cannot exceed 0 MW. I can add a unit test to make sure this is actually being enforced correctly.

[sonarqubecloud]

Quality Gate passed

Issues
21 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[BDonnot]

Hello,

Regarding the ability to increase the load, this is only possible if the allowed ramping is non-zero.

Does having a ramping up of 0 would mean this is not possible to "reconnect" the loads to the grid ?

For example, if you "curtail" 10 MW of loads at 09:00 maybe the issue that lead to this measure disappeared. And you can "reconnect" these 10MW at say 13:00 for example. We definitely want to be able to do this.

Personally I have only used it to decrease load, but their might be scenarios where the opposite might be wanted or allowed.

This is true, but I think this is "too" generic and would be really hard to set-up to represent "correctly" a powergrid issue.

"Because, I believe, that giving a certain amount of MW would be problematic. For example, if a load would consume 13MW, but the agent ask to decrease it's load by 14MW, what happens ? It now injects 1MW in the grid ? This is unclear and might be totally unrealistic :-/"
That is not the intended behaviour, I implemented it so that the load cannot exceed 0 MW. I can add a unit test to make sure this is actually being enforced correctly.

This is great I did not saw that.

Still, i think the issue with giving only MW are that it is not easy to set things up correctly (from the design of the environment perspective) and that it would be hard for the agent to manage.

Grid2op can already modifies the loads with additive value on loads (and generator) if you use directly the action for that (something like) :

env.action_space({"injection": {"loads_p": XXX}})

And I think this covers what you wanted to do.

However, the feature you target is really interesting. And I think it would be better to frame it as "ratio" (like curtailment) that would act both on load_p and load_q at the same time. And of course the ratio would be limited between 0 and 1 (or 0% and 100%).

This ratio view would also limit the need for ramps (which are not present in reality, openning a switch might drop 100% of a any load in a few milliseconds).

And, in your current implementation, this would not break too many things I believe.

What do you think ?

[DEUCE1957]

Hej Benjamin apologies for the late response (was at a conference).

Does having a ramping up of 0 would mean this is not possible to "reconnect" the loads to the grid ?

For example, if you "curtail" 10 MW of loads at 09:00 maybe the issue that lead to this measure disappeared. And you can "reconnect" these 10MW at say 13:00 for example. We definitely want to be able to do this.

Aye with the "positive flexibility" it is possible to 'undo' previous curtailments of load. So if I ask for -10MW at 09:00 (consume 10 MW less than I would have otherwise) I can ask for +10MW at 13:00 to restore it to the original load.

However, the feature you target is really interesting. And I think it would be better to frame it as "ratio" (like curtailment) that would act both on load_p and load_q at the same time. And of course the ratio would be limited between 0 and 1 (or 0% and 100%).

I do like that idea! Perhaps like curtailment we can have both a mw and ratio version. I can reformulate the current as flexibility_mw, get it to pass the tests and then add flexibility (without '_mw') as the ratio? Will need to see if the logic needs to be moved from redispatch to curtailment then.