Issue when executing redispatching

[camiloromers]

I have experienced a weird behavior when played with redispatching. In the following code, I tried to compare do nothing actions against redispatch a hydro unit as follows:

import grid2op

env = grid2op.make('wcci_test')

# Run Game from specific ts
# Compare redispatching VS DoNothing
t0, tf = 7163, 7168

# Run Do nothing
print ('\nDo nothing results ===')
env.chronics_handler.tell_id(183)
obs = env.reset()
print(env.chronics_handler.get_name())

env.fast_forward_chronics(t0)
for i in range(tf-t0+1):
    action = {} # Do nothing
    obs, reward, done, info = env.step(env.action_space(action))
    print ('Hydro MW: {:2f} MW at ts {:1d}'.format(obs.prod_p[8], t0+i))

# Run Redispatching
print ('\nRedispatching results === ->action +10MW every time step')
env.chronics_handler.tell_id(183)
obs = env.reset()
print(env.chronics_handler.get_name())

env.fast_forward_chronics(t0)
for i in range(tf-t0+1):
    action = {'redispatch': [(8, +10)]} # Re dispatch +increase 10 hydro
    obs, reward, done, info = env.step(env.action_space(action))
    print ('Hydro MW: {:2f} MW at ts {:1d}'.format(obs.prod_p[8], t0+i))
    print (info['exception'])

As you will see in the results, at time step 7163, 7164, 7165 the re-dispatching is executing normal. In my opinion, the problem arises at time step 7165 where I get an exception and after this, because according to the dispatch the units is 0 [MW], the module interprets like he cannot redispatching a unit because is "off" but it is not because I have been applying the action to increase 10 MW every time step.

The cumulative values behaves normal until 7165 where effectively the unit 8 should be around 50 MW, but after this, it gives a incorrect value.

[Tezirg]

EDITED the issue to call env.chronics_handler.tell_id(183) before env.reset for the second case with redispatch. (So that both loops run on the same scenario)

Current output:

Do nothing results ===
Scenario_february_40
Hydro MW: 19.200001 MW at ts 7163
Hydro MW: 9.000000 MW at ts 7164
Hydro MW: 0.000000 MW at ts 7165
Hydro MW: 0.000000 MW at ts 7166
Hydro MW: 0.000000 MW at ts 7167
Hydro MW: 0.000000 MW at ts 7168

Redispatching results === ->action +10MW every time step
Scenario_february_40
Hydro MW: 29.200001 MW at ts 7163
[]
Hydro MW: 29.000000 MW at ts 7164
[]
Hydro MW: 20.000000 MW at ts 7165
[Grid2OpException AmbiguousAction InvalidRedispatching InvalidRedispatching('Impossible to dispatched a turned off generator',)]
Hydro MW: 20.000000 MW at ts 7166
[Grid2OpException AmbiguousAction InvalidRedispatching InvalidRedispatching('Impossible to dispatched a turned off generator',)]
Hydro MW: 20.000000 MW at ts 7167
[Grid2OpException AmbiguousAction InvalidRedispatching InvalidRedispatching('Impossible to dispatched a turned off generator',)]
Hydro MW: 20.000000 MW at ts 7168
[Grid2OpException AmbiguousAction InvalidRedispatching InvalidRedispatching('Impossible to dispatched a turned off generator',)]

Expected output :

Do nothing results ===
Scenario_february_40
Hydro MW: 19.200001 MW at ts 7163
Hydro MW: 9.000000 MW at ts 7164
Hydro MW: 0.000000 MW at ts 7165
Hydro MW: 0.000000 MW at ts 7166
Hydro MW: 0.000000 MW at ts 7167
Hydro MW: 0.000000 MW at ts 7168

Redispatching results === ->action +10MW every time step
Scenario_february_40
Hydro MW: 29.200001 MW at ts 7163
[]
Hydro MW: 29.000000 MW at ts 7164
[]
Hydro MW: 30.000000 MW at ts 7165
[]
Hydro MW: 40.000000 MW at ts 7166
[]
Hydro MW: 50.000000 MW at ts 7167
[]
Hydro MW: 60.000000 MW at ts 7168
[]

[BDonnot]

Hello,

With the latest grid2op version (that we'll release probably tuesday or wednesday), this problem is "fixed". We put in the parameters some flag to activate / deactivate the possibility to perform redispatching action on turned off generators and another one to ignore gen_min_downtime and gen_min_uptime.

However, it appears that this action will not be performed regardless.

Indeed, due to ramping, if you want to increase the hydro of 10 MW you need other generators to absorbs that, and that's not possible on the grid.

I'll send a piece of code when it will be ready.

[BDonnot]

Basically, the problem, once you can indeed ignore the downtimes and all these stuff, that the grid modification are so sharp (always saturating something, either pmin, pmax, the ramp min or ramp max) that it's a real issue to use redispatching on this condition.

You need first to start up some generator, but not too high otherwise you'll consume all your ramps.
Then you need to carefully reduce them while you increase the redispatching. Basically, it's close to impossible, even for a human that work on that, do to redispatching on this environment.

And problem is not grid2op, but rather the fact that in your case, everything is already at maximum. So you need to be careful and study each time step...

[camiloromers]

But once you redispatch a unit, the others are not modified at the same time in grid2op? or you (as a user) need to decrease the MW of the others gens?

[BDonnot]

Hello,

So this week-end, after quite some work, I finally manage to get a reasonable behavior of the redispatching in this case, whithout impacting too much the current one (and whithout increase too much the computation time). Long story short, the "algorithm" that handles redispatching is now directly a solver, and the redispatching is cast into a minimization problem.

If you run the following, slightly adapted, script:

import grid2op
import numpy as np
import pdb
import sys
env = grid2op.make('wcci_test')
np.set_printoptions(precision=2)
# Run Game from specific ts
# Compare redispatching VS DoNothing
t0, tf = 7163, 7168

# Run Redispatching
env.chronics_handler.tell_id(183)
obs = env.reset()
print("Env preparation (start enough generators)")
# stop before the time step to start up some generators (you can modify)
id_before = 10
env.fast_forward_chronics(t0-id_before)
obs = env.get_obs()

# start each generator that can be started
gen_disp_orig = [2, 3, 10, 13, 16]  # some dispatchable generators
ratio = 0.3  # fine tune to max out the production available
array_before = [(el, ratio * env.gen_max_ramp_up[el]) for el in gen_disp_orig]
act2 = env.action_space({'redispatch': array_before})
for i in range(id_before):
    # print(act2)
    prev_p = obs.prod_p
    obs, reward, done, info = env.step(act2)
    this_p = obs.prod_p
print("I turned on +{:.2f}MW before starting to ramp up the dump".format(np.sum(obs.prod_p[gen_disp_orig])))

print('\nRedispatching results === ->action +10MW every time step')
dispatch_val = 10
new_ratio = - ratio * dispatch_val / np.sum(act2._redispatch)
array_before = [(el, new_ratio * env.gen_max_ramp_up[el]) for el in gen_disp_orig]
act2 = env.action_space({'redispatch': array_before})
print("actual dispatch init: {}".format(obs.actual_dispatch[gen_disp_orig]))
for i in range(tf-t0+1):
    action = env.action_space({'redispatch': [(8, dispatch_val)]})
    if np.sum(obs.prod_p[gen_disp_orig]) > 0.:
        action += act2
    prev_p = obs.prod_p
    obs, reward, done, info = env.step(action)
    print("done: {}".format(done))
    this_p = obs.prod_p
    print('\tHydro MW: {:2f} MW at ts {:1d}'.format(obs.prod_p[8], t0+i))
    print('\tenv target dispatch for hydro {}'.format(obs.target_dispatch[8]))
    if info["exception"]:
        print (info['exception'])

you get the following result:

Env preparation (start enough generators)
I turned on +0.00MW before starting to ramp up the dump

Redispatching results === ->action +10MW every time step
actual dispatch init: [0. 0. 0. 0. 0.]
done: False
	Hydro MW: 29.200001 MW at ts 7163
	env target dispatch for hydro 10.0
done: False
	Hydro MW: 29.000000 MW at ts 7164
	env target dispatch for hydro 20.0
done: False
	Hydro MW: 30.000000 MW at ts 7165
	env target dispatch for hydro 30.0
done: False
	Hydro MW: 36.250000 MW at ts 7166
	env target dispatch for hydro 40.0
done: False
	Hydro MW: 39.439999 MW at ts 7167
	env target dispatch for hydro 50.0
done: False
	Hydro MW: 41.230000 MW at ts 7168
	env target dispatch for hydro 60.0

This is not perfect, but that's a problem in the original data. If you want more redispatching, you can change the value of the variable id_before = 0 to set it to 20 for example [this means you anticpate 20 time steps in advance to start some production that can compensate your redispatching] and you'll end up with:

Env preparation (start enough generators)
I turned on +75.93MW before starting to ramp up the dump

Redispatching results === ->action +10MW every time step
actual dispatch init: [ 8.37  8.37 16.74 16.74 25.71]
done: False
	Hydro MW: 19.597042 MW at ts 7163
	env target dispatch for hydro 0.3968343734741211
done: False
	Hydro MW: 19.395306 MW at ts 7164
	env target dispatch for hydro 10.396834373474121
done: False
	Hydro MW: 20.396883 MW at ts 7165
	env target dispatch for hydro 20.396835327148438
done: False
	Hydro MW: 30.396908 MW at ts 7166
	env target dispatch for hydro 30.396835327148438
done: False
	Hydro MW: 40.396908 MW at ts 7167
	env target dispatch for hydro 40.39683532714844
done: False
	Hydro MW: 50.396908 MW at ts 7168
	env target dispatch for hydro 50.39683532714844

which is approximately the desired behaviour.

NB Now redispatching acts a bit differently that before. If there was an actual dispatch of -10.5 for some reason (ie this generator compensate the dispatch made on others) at a certain time step, and you ask +10 on the same generator at the same time step, the target value will now be -0.5. Before it would have been +10.

NB This behaviour will be pushed on version 0.9, most likely Tuesday.

[BDonnot]

Fixed (if we can say...) in version 0.9.0.