search

rte-france / Grid2Op

Grid2Op a testbed platform to model sequential decision making in power systems.
https://grid2op.readthedocs.io/
Mozilla Public License 2.0
288 stars 116 forks source link

Per unit value of selected observations #453

Closed AvisP closed 1 year ago

AvisP commented 1 year ago

Environment

Is it possible to obtain per unit values of observations for v_ex, load_p and gen_p? In obs_attr_to_keep. I don't see any option to specify per unit values. Currently I am just obtaining the actual values and using obs_space_kwargs to manually define the values I should divide by to obtain the per unit values. For a large network it becomes difficult to manually specify them, is there an easier way? Thanks

BDonnot commented 1 year ago

Hello,

Grid2op represents the "reality". It basically emulates what you can observe from sensors.

"Per unit" values depend on an underlying models and equations. I want to keep grid2op totally agnostic of any kind of power system model (DC, AC, dynamic, anything else etc.).

These are the reasons why grid2op give the "real" values that could be measured in Amps, kV, MW, deg etc. and NOT in per unit. If you want per unit, you have to come up with a model of the grid and then do the per unit yourself (or use the one in pandapower if you use PandaPowerBackend or lightsim2grid if you use the LightSimBackend)

Illustration of having "power system equations related information" in grid2op

if you model a transformer (in a standard 3 phases model) in "star" or in "pi" you end up with different x values and different equations in the AC formulation. But at the end, the active, reactive, voltage, current etc. will be the same regardless of the trafo model that you chose. I don't want in grid2op to force a modelling in "t" or in "pi" for the "backend" (see eg https://pandapower.readthedocs.io/en/v2.13.1/elements/trafo.html#electric-model).

Just giving an "r" and "x" and an "h" is not enough in this case. You have to specify if you are in a "t" or in a "pi" transformer model too.

It's similar for "per unit". You have different kind of "per unit" depending on the application and the underlying grid modelling. And I don't want to "force" backends to comply with a single type of model (or to convert from their underlying equations to the "grid2op equations" - converting data is often a terrible idea)