Open marota opened 7 months ago
Hello,
We should always verify (obs_simulate.prod_p==obs.prod_p) when simulating do nothing on the current state
I disagree. A simulation is NOT the current sate.
For example if you have a different solver for simulation or the reality, or if you have noisy observation or if you use different parameters for the solvers in simulation and in the environment (and i'm sure lots of other reasons).
That being said, these are not the issue you faced here.
Your problem is probably related to the slack, only the last generator is modified in your example. When you do a "step" compared to when you do a simulation, you don't start with the exact same "state" (not the same input passed to the solver) so you might end up with different results (slack compensation does not work the same way).
This not a bug grid2op side, this is just yet another case where "simulation is not reality", even in this simplified settings.
There might be a difference in behaviour different than "only the slack" as in fact (what you did not show) all the generators changed, not only the last one. Which is weird indeed.
From my understanding previous dispatch is counted twice on the current state when doing a simulation with no action. This where this is not clear to me. From the forecasts, you actually take the forecasted chronics and apply the actual dispatch on it which is relevant. But on the current state, it is already applied, so why reapplying it ?
And when doing-nothing in this configuration, I would still expect the simulation to return the same productions as in the initial observation. But here the productions where dispatch has been applied some steps before are not the same anymore. This is not only slack related
And when doing-nothing in this configuration, I would still expect the simulation to return the same productions as in the initial observation.
In the general case no it will not, even without noise or with the same solver.
Initialisation of the powerflow will be different so output might be different. But it's not what caused the "issue" you showed I agree.
The problem here is that the "simulate" is properly defined for redispatching. There are no clear specifications on what it should do in all cases, because redispatching is a "time dependant" attribute and "simulating" time dependant attribute when the time does not change is... not clear.
A clear specification for the behaviour of redispatching in all cases should be done. @marota can you do that for (suppose t is the current step):
The bug is that the "actual_dispatch" is not updated correctly in the "sim_obs": it should be doubled as you said.
And the specifications should also holds for storage units (with the charge and the impact on generators) and the curtailment.
And take into account the case where the redispatching action is "too strong" and cannot be met at "the first time".
A "model for simulate with time_step=0
" is also needed if we chain "simulation" (see #651) this is also related to the issue that get_current_date()
is also a time dependant attribute.
Environment
1.9.8
ubuntu20.04, ...
Bug description
When simulating on the current state, we would expect the same injections, in particular the same productions. This is verified when no action is performed for instance. But once a redispatch action is applied at some step, the later simulations on the current state don't verify that any more. This leads to wrong simulation result.
How to reproduce
Command line
Code snippet
Current output
Expected output