-
Notifications
You must be signed in to change notification settings - Fork 115
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
Simulation on current state reapply actual_dispatch when a redispatch action has been applied before #598
Comments
Hello,
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 |
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". |
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
# command line used if any
Code snippet
Current output
Expected output
The text was updated successfully, but these errors were encountered: