Observation¶
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 thegrid2op.Environment.Environment
. The only information about the Environment the BaseAgent should have is through thegrid2op.Observation.BaseObservation
and thegrid2op.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) 

int 
1 

float 

float 

float 

float 

float 

int 

bool 

int 

int 

int 

int 

int 

float 

float 
(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.)
Detailed Documentation by class¶
Classes:

Basic class representing an observation. 

This class represent a complete observation, where everything on the powergrid can be observed without any noise. 

Helper that provides useful functions to manipulate 

class
grid2op.Observation.
BaseObservation
(obs_env=None, action_helper=None, seed=None)[source]¶ Basic class representing an observation.
All observation must derive from this class and implement all its abstract methods.

action_helper
¶ A representation of the possible action space.

year
¶ The current year
 Type
int

month
¶ The current month (1 = january, 12 = december)
 Type
int

day
¶ The current day of the month (1 = first day of the month)
 Type
int

hour_of_day
¶ The current hour of the day (from O to 23)
 Type
int

minute_of_hour
¶ The current minute of the current hour (from 0 to 59)
 Type
int

day_of_week
¶ The current day of the week (monday = 0 and sunday = 6)
 Type
int

prod_p
¶ The active production value of each generator (expressed in MW).
 Type
numpy.ndarray
, dtype:float

prod_q
¶ The reactive production value of each generator (expressed in MVar).
 Type
numpy.ndarray
, dtype:float

prod_v
¶ The voltage magnitude of the bus to which each generator is connected (expressed in kV).
 Type
numpy.ndarray
, dtype:float

load_p
¶ The active load value of each consumption (expressed in MW).
 Type
numpy.ndarray
, dtype:float

load_q
¶ The reactive load value of each consumption (expressed in MVar).
 Type
numpy.ndarray
, dtype:float

load_v
¶ The voltage magnitude of the bus to which each consumption is connected (expressed in kV).
 Type
numpy.ndarray
, dtype:float

p_or
¶ The active power flow at the origin end of each powerline (expressed in MW).
 Type
numpy.ndarray
, dtype:float

q_or
¶ The reactive power flow at the origin end of each powerline (expressed in MVar).
 Type
numpy.ndarray
, dtype:float

v_or
¶ The voltage magnitude at the bus to which the origin end of each powerline is connected (expressed in kV).
 Type
numpy.ndarray
, dtype:float

a_or
¶ The current flow at the origin end of each powerline (expressed in A).
 Type
numpy.ndarray
, dtype:float

p_ex
¶ The active power flow at the extremity end of each powerline (expressed in MW).
 Type
numpy.ndarray
, dtype:float

q_ex
¶ The reactive power flow at the extremity end of each powerline (expressed in MVar).
 Type
numpy.ndarray
, dtype:float

v_ex
¶ The voltage magnitude at the bus to which the extremity end of each powerline is connected (expressed in kV).
 Type
numpy.ndarray
, dtype:float

a_ex
¶ The current flow at the extremity end of each powerline (expressed in A).
 Type
numpy.ndarray
, dtype:float

rho
¶ The capacity of each powerline. It is defined at the observed current flow divided by the thermal limit of each powerline (no unit)
 Type
numpy.ndarray
, dtype:float

topo_vect
¶ For each object (load, generator, ends of a powerline) it gives on which bus this object is connected in its substation. See
grid2op.Backend.Backend.get_topo_vect()
for more information. Type
numpy.ndarray
, dtype:int

line_status
¶ Gives the status (connected / disconnected) for every powerline (
True
at position i means the powerline i is connected) Type
numpy.ndarray
, dtype:bool

timestep_overflow
¶ Gives the number of time steps since a powerline is in overflow.
 Type
numpy.ndarray
, dtype:int

time_before_cooldown_line
¶ For each powerline, it gives the number of time step the powerline is unavailable due to “cooldown” (see
grid2op.Parameters.NB_TIMESTEP_COOLDOWN_LINE
for more information). 0 means the an action will be able to act on this same powerline, a number > 0 (eg 1) means that an action at this time step cannot act on this powerline (in the example the agent have to wait 1 time step) Type
numpy.ndarray
, dtype:int

time_before_cooldown_sub
¶ Same as
BaseObservation.time_before_cooldown_line
but for substations. For each substation, it gives the number of timesteps to wait before acting on this substation (see seegrid2op.Parameters.NB_TIMESTEP_COOLDOWN_SUB
for more information). Type
numpy.ndarray
, dtype:int

time_next_maintenance
¶ For each powerline, it gives the time of the next planned maintenance. For example if there is:
1 at position i it means that the powerline i will be disconnected for maintenance operation at the next time step.
0 at position i means that powerline i is disconnected from the powergrid for maintenance operation at the current time step.
1 at position i means that powerline i will not be disconnected for maintenance reason for this episode.
k > 1 at position i it means that the powerline i will be disconnected for maintenance operation at in k time steps
 Type
numpy.ndarray
, dtype:int

duration_next_maintenance
¶ For each powerline, it gives the number of time step that the maintenance will last (if any). This means that, if at position i of this vector:
there is a 0: the powerline is not disconnected from the grid for maintenance
there is a 1, 2, … the powerline will be disconnected for at least 1, 2, … timestep (NB in all case, the powerline will stay disconnected until a
grid2op.BaseAgent.BaseAgent
performs the propergrid2op.BaseAction.BaseAction
to reconnect it).
 Type
numpy.ndarray
, dtype:int

target_dispatch
¶ For each generators, it gives the target redispatching, asked by the agent. This is the sum of all redispatching asked by the agent for during all the episode. It for each generator it is a number between:  pmax and pmax. Note that there is information about all generators there, even the one that are not dispatchable.
 Type
numpy.ndarray
, dtype:float

actual_dispatch
¶ For each generators, it gives the redispatching currently implemented by the environment. Indeed, the environment tries to implement at best the
BaseObservation.target_dispatch
, but sometimes, due to physical limitation (pmin, pmax, ramp min and ramp max) it cannot. In this case, only the best possible redispatching is implemented at the current time step, and this is what this vector stores. Note that there is information about all generators there, even the one that are not dispatchable. Type
numpy.ndarray
, dtype:float
Methods:
Return self==value.
Initialize self.
Generic (shallow and deep) copying operations.

__eq__
(other)[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
Test the equality of two observations.
2 actions are said to be identical if the have the same impact on the powergrid. This is unlrelated to their respective class. For example, if an BaseAction is of class
BaseAction
and doesn’t act on the _injection, it can be equal to a an BaseAction of derived classTopologyAction
(if the topological modification are the same of course).This implies that the attributes
BaseAction.authorized_keys
is not checked in this method.Note that if 2 actions doesn’t act on the same powergrid, or on the same backend (eg number of loads, or generators is not the same in self and other, or they are not in the same order) then action will be declared as different.
Known issue if two backend are different, but the description of the _grid are identical (ie all n_gen, n_load, n_line, sub_info, dim_topo, all vectors *_to_subid, and *_pos_topo_vect are identical) then this method will not detect the backend are different, and the action could be declared as identical. For now, this is only a theoretical behaviour: if everything is the same, then probably, up to the naming convention, then the powergrid are identical too.
 Parameters
other (
BaseObservation
) – An instance of class BaseAction to which “self” will be compared. Returns
 Return type
True
if the action are equal,False
otherwise.

__init__
(obs_env=None, action_helper=None, seed=None)[source]¶ Initialize self. See help(type(self)) for accurate signature.

bus_connectivity_matrix
()[source]¶ If we denote by nb_bus the total number bus of the powergrid (you can think of a “bus” being a “node” if you represent a powergrid as a graph [mathematical object, not a plot] with the lines being the “edges”].
The bus_connectivity_matrix will have a size nb_bus, nb_bus and will be made of 0 and 1.
If bus_connectivity_matrix[i,j] = 1 then at least a power line connects bus i and bus j. Otherwise, nothing connects it.
 Returns
res – The bus connectivity matrix
 Return type
numpy.ndarray
, shape:nb_bus,nb_bus dtype:float
Notes
By convention we say that a bus is connected to itself. So the diagonal of this matrix is 1.
For now this matrix is stored as a dense matrix. Support for sparse matrix will be added in the future.

connectivity_matrix
()[source]¶ Computes and return the “connectivity matrix” con_mat. if “dim_topo = 2 * n_line + n_prod + n_conso” It is a matrix of size dim_topo, dim_topo, with values 0 or 1. For two objects (lines extremity, generator unit, load) i,j :
 if i and j are connected on the same substation:
if conn_mat[i,j] = 0 it means the objects id’ed i and j are not connected to the same bus.
if conn_mat[i,j] = 1 it means the objects id’ed i and j are connected to the same bus, are both end of the same powerline
if i and j are not connected on the same substation then`conn_mat[i,j] = 0` except if i and j are the two extremities of the same power line, in this case conn_mat[i,j] = 1.
By definition, the diagonal is made of 0.
 Returns
res – The connectivity matrix, as defined above
 Return type
numpy.ndarray
, shape:dim_topo,dim_topo, dtype:float
Notes
For now this matrix is stored as a dense matrix. Support for sparse matrix will be added in the future.
Examples
If you want to know if powerline 0 is connected at its “extremity” side with the load of id 0 you can do
import grid2op env = grid2op.make() obs = env.reset() # retrieve the id of extremity of powerline 1: id_lineex_0 = obs.line_ex_pos_topo_vect[0] id_load_1 = obs.load_pos_topo_vect[0] # get the connectivity matrix connectivity_matrix = obs.connectivity_matrix() # know if the objects are connected or not are_connected = connectivity_matrix[id_lineex_0, id_load_1] # as `are_connected` is 1.0 then these objects are indeed connected
And now, supposes we do an action that changes the topology of the substation to which these two objects are connected, then we get (same example continues)
topo_action = env.action_space({"set_bus": {"substations_id": [(1, [1,1,1,2,2,2])]}}) print(topo_action) # This action will: #  NOT change anything to the injections #  NOT perform any redispatching action #  NOT force any line status #  NOT switch any line status #  NOT switch anything in the topology #  Set the bus of the following element: #  assign bus 1 to line (extremity) 0 [on substation 1] #  assign bus 1 to line (origin) 2 [on substation 1] #  assign bus 1 to line (origin) 3 [on substation 1] #  assign bus 2 to line (origin) 4 [on substation 1] #  assign bus 2 to generator 0 [on substation 1] #  assign bus 2 to load 0 [on substation 1] obs, reward, done, info = env.step(topo_action) # and now retrieve the matrix connectivity_matrix = obs.connectivity_matrix() # know if the objects are connected or not are_connected = connectivity_matrix[id_lineex_0, id_load_1] # as `are_connected` is 0.0 then these objects are not connected anymore # this is visible when you "print" the action (see above) in the two following lines: #  assign bus 1 to line (extremity) 0 [on substation 1] #  assign bus 2 to load 0 [on substation 1] # > one of them is on bus 1 [line (extremity) 0] and the other on bus 2 [load 0]

copy
()[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
Make a (deep) copy of the observation.
 Returns
res – The deep copy of the observation
 Return type

get_forecasted_inj
(time_step=1)[source]¶ This function allows you to retrieve directly the “forecast” injections for the step time_step.
We remind that the environment, under some conditions, can produce these forecasts automatically. This function allows to retrieve what has been forecast.
 Parameters
time_step (
int
) – The horizon of the forecast (given in number of time steps) Returns
prod_p_f (
numpy.ndarray
) – The forecast generators active valuesprod_v_f (
numpy.ndarray
) – The forecast generators voltage setpoinsload_p_f (
numpy.ndarray
) – The forecast load active consumptionload_q_f (
numpy.ndarray
) – The forecast load reactive consumption

get_time_stamp
()[source]¶ Get the time stamp of the current observation as a datetime.datetime object

reset
()[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
Resetting a single observation is unlikely to do what you want to do.
Reset the
BaseObservation
to a blank state, where everything is set to eitherNone
or to its default value.

set_game_over
()[source]¶ Set the observation to the “game over” state:
all powerlines are disconnected
all loads are 0.
all prods are 0.
etc.

simulate
(action, time_step=1)[source]¶ This method is used to simulate the effect of an action on a forecast powergrid state. This forecast state is built upon the current observation.
The forecast are pre computed by the environment.
More concretely, if not deactivated by the environment (see
grid2op.Environment.BaseEnv.deactivate_forecast()
) and the environment has the capacity to generate these forecasts (which is the case in most grid2op environments) this function will simulate the effect of doing an action now and return the “next state” (often the state you would get at time t + 5 mins) if you were to do the action at this step.It has the same return value as the
grid2op.Environment.Environment.step()
function. Parameters
action (
grid2op.Action.Action
) – The action to simulatetime_step (
int
) – The time step of the forecasted grid to perform the action on. If no forecast are available for this time step, agrid2op.Exceptions.NoForecastAvailable
is thrown.
 Raises
grid2op.Exceptions.NoForecastAvailable – if no forecast are available for the time_step querried.
 Returns
simulated_observation (
grid2op.Observation.Observation
) – agent’s observation of the current environment after the application of the action “act” on the the current state.reward (
float
) – amount of reward returned after previous actiondone (
bool
) – whether the episode has ended, in which case further step() calls will return undefined resultsinfo (
dict
) – contains auxiliary diagnostic information (helpful for debugging, and sometimes learning)
Notes
This is a simulation in the sense that the “next grid state” is not the real grid state you will get. As you don’t know the future, the “injections you forecast for the next step” will not be the real injection you will get in the next step.
Also, in some circumstances, the “Backend” (ie the powerflow) used to do the simulation may not be the same one as the one used by the environment. This is to model a real fact: as accurate your powerflow is, it does not model all the reality (“all models are wrong”). Having a different solver for the environment ( “the reality”) than the one used to anticipate the impact of the action (this “simulate” function) is a way to represent this fact.
Examples
To simulate what would be the effect of the action “act” if you were to take this action at this step you can do the following:
import grid2op # retrieve an environment env = grid2op.make() # retrieve an observation, this is the same for all observations obs = env.reset() # and now you can simulate the effect of doing nothing in the next time step act = env.action_space() # this can be any action that grid2op understands simulated_obs, simulated_reward, simulated_done, simulated_info = obs.simulate(act) # `simulated_obs` will be the "observation" after the application of action `act` on the # " forecast of the grid state (it will be the "forecast state at time t+5mins usually) # `simulated_reward` will be the reward for the same action on the same forecast state # `simulated_done` will indicate whether or not the simulation ended up in a "game over" # `simulated_info` gives extra information on this forecast state

state_of
(_sentinel=None, load_id=None, gen_id=None, line_id=None, substation_id=None)[source]¶ Return the state of this action on a give unique load, generator unit, powerline of substation. Only one of load, gen, line or substation should be filled.
The querry of these objects can only be done by id here (ie by giving the integer of the object in the backed). The
ActionSpace
has some utilities to access them by name too. Parameters
_sentinel (
None
) – Used to prevent positional parameters. Internal, do not use.load_id (
int
) – ID of the load we want to inspectgen_id (
int
) – ID of the generator we want to inspectline_id (
int
) – ID of the powerline we want to inspectsubstation_id (
int
) – ID of the substation we want to inspect
 Returns
res – A dictionnary with keys and value depending on which object needs to be inspected:
if a load is inspected, then the keys are:
”p” the active value consumed by the load
”q” the reactive value consumed by the load
”v” the voltage magnitude of the bus to which the load is connected
”bus” on which bus the load is connected in the substation
”sub_id” the id of the substation to which the load is connected
if a generator is inspected, then the keys are:
”p” the active value produced by the generator
”q” the reactive value consumed by the generator
”v” the voltage magnitude of the bus to which the generator is connected
”bus” on which bus the generator is connected in the substation
”sub_id” the id of the substation to which the generator is connected
”actual_dispatch” the actual dispatch implemented for this generator
”target_dispatch” the target dispatch (cumulation of all previously asked dispatch by the agent) for this generator
if a powerline is inspected then the keys are “origin” and “extremity” each being dictionnary with keys:
”p” the active flow on line end (extremity or origin)
”q” the reactive flow on line end (extremity or origin)
”v” the voltage magnitude of the bus to which the line end (extremity or origin) is connected
”bus” on which bus the line end (extremity or origin) is connected in the substation
”sub_id” the id of the substation to which the generator is connected
”a” the current flow on the line end (extremity or origin)
In the case of a powerline, additional information are:
”maintenance”: information about the maintenance operation (time of the next maintenance and duration of this next maintenance.
”cooldown_time”: for how many timestep i am not supposed to act on the powerline due to cooldown (see
grid2op.Parameters.Parameters.NB_TIMESTEP_COOLDOWN_LINE
for more information)
if a substation is inspected, it returns the topology to this substation in a dictionary with keys:
”topo_vect”: the representation of which object is connected where
”nb_bus”: number of active buses in this substations
”cooldown_time”: for how many timestep i am not supposed to act on the substation due to cooldown (see
grid2op.Parameters.Parameters.NB_TIMESTEP_COOLDOWN_SUB
for more information)
 Return type
dict
 Raises
Grid2OpException – If _sentinel is modified, or if None of the arguments are set or alternatively if 2 or more of the parameters are being set.

abstractmethod
update
(env, with_forecast=True)[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\ This is carried out automatically by the environment in env.step
Update the actual instance of BaseObservation with the new received value from the environment.
An observation is a description of the powergrid perceived by an agent. The agent takes his decision based on the current observation and the past rewards.
This method update receive complete detailed information about the powergrid, but that does not mean an agent sees everything. For example, it is possible to derive this class to implement some noise in the generator or load, or flows to mimic sensor inaccuracy.
It is also possible to give fake information about the topology, the line status etc.
In the Grid2Op framework it’s also through the observation that the agent has access to some forecast (the way forecast are handled depends are implemented in this class). For example, forecast data (retrieved thanks to chronics_handler) are processed, but can be processed differently. One can apply load / production forecast to each _grid state, or to make forecast for one “reference” _grid state valid a whole day and update this one only etc. All these different mechanisms can be implemented in Grid2Op framework by overloading the update observation method.
This class is really what a dispatcher observes from it environment. It can also include some temperatures, nebulosity, wind etc. can also be included in this class.
Notes
We strongly recommend to call
BaseObservation.reset
when implementing this function.


class
grid2op.Observation.
CompleteObservation
(obs_env=None, action_helper=None, seed=None)[source]¶ This class represent a complete observation, where everything on the powergrid can be observed without any noise.
This is the only
BaseObservation
implemented (and used) in Grid2Op. Other type of observation, for other usage can of course be implemented following this example.It has the same attributes as the
BaseObservation
class. Only one is added here.For a
CompleteObservation
the unique representation as a vector is:BaseObservation.year
the year [1 element]BaseObservation.month
the month [1 element]BaseObservation.day
the day [1 element]BaseObservation.hour_of_day
the hour of the day [1 element]BaseObservation.minute_of_hour
minute of the hour [1 element]BaseObservation.day_of_week
the day of the week. Monday = 0, Sunday = 6 [1 element]BaseObservation.prod_p
the active value of the productions [grid2op.Space.GridObjects.n_gen
elements]BaseObservation.prod_q
the reactive value of the productions [grid2op.Space.GridObjects.n_gen
elements]BaseObservation.prod_q
the voltage setpoint of the productions [grid2op.Space.GridObjects.n_gen
elements]BaseObservation.load_p
the active value of the loads [grid2op.Space.GridObjects.n_load
elements]BaseObservation.load_q
the reactive value of the loads [grid2op.Space.GridObjects.n_load
elements]BaseObservation.load_v
the voltage setpoint of the loads [grid2op.Space.GridObjects.n_load
elements]BaseObservation.p_or
active flow at origin of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.q_or
reactive flow at origin of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.v_or
voltage at origin of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.a_or
current flow at origin of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.p_ex
active flow at extremity of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.q_ex
reactive flow at extremity of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.v_ex
voltage at extremity of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.a_ex
current flow at extremity of powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.rho
line capacity used (current flow / thermal limit) [grid2op.Space.GridObjects.n_line
elements]BaseObservation.line_status
line status [grid2op.Space.GridObjects.n_line
elements]BaseObservation.timestep_overflow
number of timestep since the powerline was on overflow (0 if the line is not on overflow)[grid2op.Space.GridObjects.n_line
elements]BaseObservation.topo_vect
representation as a vector of the topology [for each element it gives its bus]. Seegrid2op.Backend.Backend.get_topo_vect()
for more information.BaseObservation.time_before_cooldown_line
representation of the cooldown time on the powerlines [grid2op.Space.GridObjects.n_line
elements]BaseObservation.time_before_cooldown_sub
representation of the cooldown time on the substations [grid2op.Space.GridObjects.n_sub
elements]BaseObservation.time_next_maintenance
number of timestep before the next maintenance (1 means no maintenance are planned, 0 a maintenance is in operation) [BaseObservation.n_line
elements]BaseObservation.duration_next_maintenance
duration of the next maintenance. If a maintenance is taking place, this is the number of timestep before it ends. [BaseObservation.n_line
elements]BaseObservation.target_dispatch
the target dispatch for each generator [grid2op.Space.GridObjects.n_gen
elements]BaseObservation.actual_dispatch
the actual dispatch for each generator [grid2op.Space.GridObjects.n_gen
elements]
Methods:
Initialize self.

__init__
(obs_env=None, action_helper=None, seed=None)[source]¶ Initialize self. See help(type(self)) for accurate signature.

from_vect
(vect, check_legit=True)[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
To reload an observation from a vector, use the “env.observation_space.from_vect()”.
Convert back an observation represented as a vector into a proper observation.
Some conversion are done silently from float to the type of the corresponding observation attribute.
 Parameters
vect (
numpy.ndarray
) – A representation of an BaseObservation in the form of a vector that is used to convert back the current observation to be equal to the vect.

to_dict
()[source]¶ Transform this observation as a dictionary. This dictionary allows you to inspect the state of this observation and is simply a shortcut of the class instance.
 Returns
 Return type
A dictionary representing the observation.

update
(env, with_forecast=True)[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\ This is carried out automatically by the environment in env.step
Update the actual instance of BaseObservation with the new received value from the environment.
An observation is a description of the powergrid perceived by an agent. The agent takes his decision based on the current observation and the past rewards.
This method update receive complete detailed information about the powergrid, but that does not mean an agent sees everything. For example, it is possible to derive this class to implement some noise in the generator or load, or flows to mimic sensor inaccuracy.
It is also possible to give fake information about the topology, the line status etc.
In the Grid2Op framework it’s also through the observation that the agent has access to some forecast (the way forecast are handled depends are implemented in this class). For example, forecast data (retrieved thanks to chronics_handler) are processed, but can be processed differently. One can apply load / production forecast to each _grid state, or to make forecast for one “reference” _grid state valid a whole day and update this one only etc. All these different mechanisms can be implemented in Grid2Op framework by overloading the update observation method.
This class is really what a dispatcher observes from it environment. It can also include some temperatures, nebulosity, wind etc. can also be included in this class.
Notes
We strongly recommend to call
BaseObservation.reset
when implementing this function.

class
grid2op.Observation.
ObservationSpace
(gridobj, env, rewardClass=None, observationClass=<class 'grid2op.Observation.CompleteObservation.CompleteObservation'>, with_forecast=True)[source]¶ Helper that provides useful functions to manipulate
BaseObservation
.BaseObservation should only be built using this Helper. It is absolutely not recommended to make an observation directly form its constructor.
This class represents the same concept as the “BaseObservation Space” in the OpenAI gym framework.

with_forecast
¶ If
True
theBaseObservation.simulate()
will be available. IfFalse
it will deactivate this possibility. If simulate function is not used, setting it toFalse
can lead to non neglectible speedups. Type
bool

observationClass
¶ Class used to build the observations. It defaults to
CompleteObservation
 Type
type

parameters
¶ Type of Parameters used to compute powerflow for the forecast.

rewardClass
¶ Class used by the
grid2op.Environment.Environment
to send information about its state to thegrid2op.BaseAgent.BaseAgent
. You can change this class to differentiate between the reward of output ofBaseObservation.simulate()
and the reward used to train the BaseAgent. Type
type

action_helper_env
¶ BaseAction space used to create action during the
BaseObservation.simulate()

reward_helper
¶ BaseReward function used by the the
BaseObservation.simulate()
function. Type
grid2op.Reward.HelperReward

obs_env
¶ Instance of the environment used by the BaseObservation Helper to provide forcecast of the grid state.
 Type
_ObsEnv

_empty_obs
¶ An instance of the observation with appropriate dimensions. It is updated and will be sent to he BaseAgent.
 Type
Methods:
Initialize self.
Generic (shallow and deep) copying operations.

__init__
(gridobj, env, rewardClass=None, observationClass=<class 'grid2op.Observation.CompleteObservation.CompleteObservation'>, with_forecast=True)[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
Env: requires
grid2op.Environment.parameters
andgrid2op.Environment.backend
to be valid

copy
()[source]¶ Warning
/!\ Internal, do not use unless you know what you are doing /!\
Perform a deep copy of the Observation space.

If you still can’t find what you’re looking for, try in one of the following pages: