Issue of case14_redisp

[djmax008]

Hi,

I am running the "case14_redisp" with "env = grid2op.make("case14_redisp", chronics_path="PATH\YOU\WANT\DATA\SAVED\TO\case14_redisp" )" I found some issues in the data file of "case14_redisp" and could you please help to check? First, the time information is missing, which might be a minor problem. Second, the definition of the thermal limit is confusing for us. I think the thermal limit is defined as apparent power in the previous version. Now it is defined as follows with significantly different magnitude. Even if I change this to the previous value, it will be changed again during the calculation. Similarly, the state.rho values also become very strange. I think it might be a bug in the program. Third, the most important issue is the setting point of generation. The setpoint of the latest version will lead to the diverge of power flow even when I take no action, which needs to be modified. Finally, I found the reward definition of "case14_redisp" is different from L2RPN, could you please provide some materials to explain the meaning of the new reward definition?

Thanks,

[jhmenke]

The IEEE14 grid used is not fully configured correctly due to missing information, which leads to weird line loading values.

I'm not a developer of grid2op, but I can try to explain the loss: Previously, only a high line loading (in %) was penalized so that the overall loadings were minimized. In the new loss, the system loss (energy lost as heat in the various components of the grid) is to be minimized, which is simlar to before, but not quite. This is the term losses_cost.

redisp_cost is a cost term derived by the summing the power produced by the generators that can be redispatched (controlled). This is to be minimized as well.

Both terms are adjusted by marginal_cost, which is the maximum cost term of the active generators that can be redispatched. This penalizes the use of the most expensive generator in general.

The goal is to not use the redispatchable generators (iirc they should model fossil fuel power plants) and minimize the overall system losses and the new loss is an approximation of that.

[BDonnot]

Thank you @jhmenke your explanation is crystal clear and totally correct :-)

The answer to the original question has been carried out in mail and a dedicated meetings.

For the community, in case someone wonder the same things:

Most of the problems came from the the reuse of l2rpn2019 data for this new environment. Let me recap here and closing this issue:

First, the time information is missing, which might be a minor problem.

The date and time information are present, as a default value is used. Data start by default on January 1st, 2019.

Second, the definition of the thermal limit is confusing for us. I think the thermal limit is defined as apparent power in the previous version. Now it is defined as follows with significantly different magnitude.

We have noticed this issue. The underlying "problem" is the voltages used in the default case14 of pandapower. A new environment will be available in the next release (0.5.7) that should be more realistic on this point of view.

Even if I change this to the previous value, it will be changed again during the calculation.

Don't try to use any data from the l2rpn 2019 environment into this one. This is a bad idea and will lead to wrong behaviour.

Similarly, the state.rho values also become very strange. I think it might be a bug in the program.

After investigation, there is not bug at all in this regard. Bug was probably due (lack of information to reproduce this bug) to the use of l2rpn 2019 environment.

The setpoint of the latest version will lead to the diverge of power flow even when I take no action, which needs to be modified.

This environment is completely different from the l2rpn2019. This is not a bug but a desired feature.

Jan-Hendrik perfectly explain the change of reward (see above post).

Thanks a lot for the constructive remarks

Benjamin