Misleading error message when redispatching action is not performed correctly

[rte-france]

Misleading error message when redispatching action is not performed correctly

[jhmenke]

self.gen_activeprod_t in BasicEnv.py line 379 is completely 0. despite observation.prod_p being

[81.3 80.1 12.6 0. 80.49025102]

I would not expect all gens to be shut off in the forecast/next timestep.

[BDonnot]

You are correct, this is a bug that I will work on in the next version.

For now, better not use "redispatch" action in simulate.

Benjamin

[BDonnot]

This bug only appear when you simulate correct ?

[jhmenke]

No, also in the step

obs, reward, done, info = env.step(act)
print(reward)
-5.0

[BDonnot]

After a quick experiment, here is what is happening:

You want to modify the setpoint (by redispatching) of the 3 controlable generators. This is totally fine.

To "fix" your action, because the redispatching action must sum to 0, an "automaton" [imagine something that has the same role as the frequency control automaton in real life] takes care of that. It can act only on dispatchable generators. But you modify all the three.

As your action does not sum to 0:

import numpy as np
import grid2op
env = grid2op.make()
act = env.action_space({"redispatch": [(0, 4.9999784936326535), (1, 4.78524395611872), (4, -9.999591852954794)]})
np.sum(act._redispatch)
# -0.21436940320342046

then the action is not implemented because the constraints "I must have a redispatching summing at 0." can't be met.

You can see that with:

obs, reward, done, info = env.step(act)
print(info["is_dipatching_illegal"])
# it prints True

The error message is completely misleading i agree some work need to be done in this case.

This error is easily "fixed" you need to provide a vector that sums at 0, like this for example:

act2 = env.action_space({"redispatch": np.array([ 4.99997849,  4.78524396,  0.        ,  0.        , -9.78522245])})
obs, reward, done, info = env.step(act2)
print(reward)
# 221.22035009361286

[jhmenke]

Hmm that's a bit weird, because the -0.21 in this case are the decrease of system losses. But i understand your idea, so i can just scale the values correctly and it should work.

[BDonnot]

This constraint of "redispatch should sum to 0." is to impose the system to always meet "sum Prod = sum Load + losses" and not interfer too much with the slack bus.
This constraints is met (more or less, up to +/- 1MW say) when the chronics have been generated.

If your vector does not sum at 0, then some agent could only decrease the values of one generator, and the slack bus would absorb all. This is only "a reasonable approximation" with a distributed slack bus (where this value is split on different generators), but some powerflows don't support this feature. That's why I added, directly in the environment, this "automaton" that enforce the redispatching vector to sum at 0.

Scaling up your vector would work in this case, but make sure that the ramps and pmin / pmax are met when you do that :-)

[jhmenke]

Sure, i have to translate the OPF results correctly, which should be doable. Now i only have the issue in simulate like you already wrote. Thanks!

[BDonnot]

Hello,

This issue should be fixed in the latest (0.5.8) grid2op issue, where i check specifically for this case and throw the appropriate error (that should then help debugging much more easily in this case).

Thanks for noticing and suggesting this improvement. If you think the issue has been solved after upgrading, feel free to close it :-)

Benjamin