observation.rst

grid2op.Observation

Observation

This page is organized as follow:

Table of Contents

Objectives

In a "reinforcement learning" framework, an grid2op.Agent receive two information before taking any action on the grid2op.Environment.Environment. One of them is the grid2op.Reward.BaseReward that tells it how well the past action performed. The second main input received from the environment is the BaseObservation. This is gives the BaseAgent partial, noisy, or complete information about the current state of the environment. This module implement a generic BaseObservation class and an example of a complete observation in the case of the Learning To Run a Power Network (l2RPN ) competition.

Compared to other Reinforcement Learning problems the L2PRN competition allows another flexibility. Today, when operating a powergrid, operators have "forecasts" at their disposal. We wanted to make them available in the L2PRN competition too. In the first edition of the L2PRN competition, was offered the functionality to simulate the effect of an action on a forecasted powergrid. This forecasted powergrid used:

• the topology of the powergrid of the last know time step
• all the injections of given in files.

This functionality was originally attached to the Environment and could only be used to simulate the effect of an action on this unique time step. We wanted in this recoding to change that:

• in an RL setting, an grid2op.Agent.BaseAgent should not be able to look directly at the grid2op.Environment.Environment. The only information about the Environment the BaseAgent should have is through the grid2op.Observation.BaseObservation and the grid2op.Reward.BaseReward. Having this principle implemented will help enforcing this principle.
• In some wider context, it is relevant to have these forecasts available in multiple way, or modified by the grid2op.Agent.BaseAgent itself (for example having forecast available for the next 2 or 3 hours, with the Agent able not only to change the topology of the powergrid with actions, but also the injections if he's able to provide more accurate predictions for example.

The BaseObservation class implement the two above principles and is more flexible to other kind of forecasts, or other methods to build a power grid based on the forecasts of injections.

Main observation attributes

In general, observations have the following attributes (if an attributes has name XXX [eg rho] it can be accessed with obs.XXX [eg obs.rho])

Name(s)	Type	Size (each)
year, month, day, hour_of_day, minute_of_hour, day_of_week	int	1
gen_p, gen_q, gen_v	float	n_gen
load_p, load_q, load_v	float	n_load
p_or, q_or, v_or, a_or	float	n_line
p_ex, q_ex, v_ex, a_ex	float	n_line
rho	float	n_line
topo_vect	int	dim_topo
line_status	bool	n_line
timestep_overflow	int	n_line
time_before_cooldown_line	int	n_line
time_before_cooldown_sub	int	n_sub
time_next_maintenance	int	n_line
duration_next_maintenance	int	n_line
target_dispatch	float	n_gen
actual_dispatch	float	n_gen
storage_charge	float	n_storage
storage_power_target	float	n_storage
storage_power	float	n_storage
gen_p_before_curtail	float	n_gen
curtailment, curtailment_limit	float	n_gen
is_alarm_illegal	bool	1
time_since_last_alarm	int	1
last_alarm	int	dim_alarms
attention_budget	int	1
max_step , current_step	int	1

(NB for concision, if a coma (",") is present in the "Name(s)" part of the column, it means multiple attributes are present. If we take the example of the first row, it means that obs.year, obs.month, etc. are all valid attributes of the observation, they are all integers and each is of size 1.)

But where is the graph ?

A powergrid can be represented as (at least) a graph (here: a mathematical object with nodes / vertices are connected by edges).

Grid2op is made in a way that the observation and action do not explicitly represents such graph. This is motivated first by performance reasons, but also because multiple "graphs" can represent equally well a powergrid.

The first one that come to mind is the graph where the nodes / vertices are the buses and the edges are the powerline. We will call this graph the "bus graph". It can be accessed in grid2op using the grid2op.Observation.BaseObservation.bus_connectivity_matrix for example. This will return a matrix with 1 when 2 buses are connected and 0 otherwise, with the convention that a bus is always connected to itself. You can think of the environments in grid2op as an environment that allows you to manipulate this graph: split some bus in sub buses by changing at which busbar some elements are connected, or removing some edges from this graph when powerlines are connected / disconnected. An important feature of this graph is that its size changes: it can have a different number of nodes at different steps!

Some methods allow to retrieve these graphs, for example:

• grid2op.Observation.BaseObservation.connectivity_matrix
• grid2op.Observation.BaseObservation.flow_bus_matrix

For more information, you can consult the gridgraph-module page.

Detailed Documentation by class

grid2op.Observation