Parameters¶

The challenge “learning to run a power network” offers different _parameters to be customized, or to learn an grid2op.Agent that will perform better for example.

This class is an attempt to group them all inside one single structure.

For now, Parameters have default value, but the can be read back / from json. Other serialization method will come soon.

Example¶

If you want to change the parameters it is better to do it at the creation of the environment.

This can be done with:

import grid2op
from grid2op.Parameters import Parameters

# Create parameters
p = Parameters()

# Disable lines disconnections due to overflows
p.NO_OVERFLOW_DISCONNECTION = True

# Allow 4 substations to be impacted each turn
p.MAX_SUB_CHANGED = 4

# Allow 10 lines actions per turn
p.MAX_LINE_STATUS_CHANGED = 10

# Give Parameters instance to make, so its used
env = grid2op.make("rte_case14_realistic", param=p)

Classes:

Parameters([parameters_path])

Main classes representing the parameters of the game.

class grid2op.Parameters.Parameters(parameters_path=None)[source]¶

Main classes representing the parameters of the game. The main parameters are described bellow.

Note that changing the values of these parameters might not be enough. If these _parameters are not used in the grid2op.Rules.RulesChecker, then modifying them will have no impact at all.

NO_OVERFLOW_DISCONNECTION¶

If set to True then the grid2op.Environment.Environment will not disconnect powerline above their thermal limit. Default is False

Type:: bool

NB_TIMESTEP_OVERFLOW_ALLOWED¶

Number of timesteps for which a soft overflow is allowed, default 2. This means that a powerline will be disconnected (if NO_OVERFLOW_DISCONNECTION is set to False) after 2 time steps above its thermal limit. This is called a “soft overflow”.

Type:: int

NB_TIMESTEP_RECONNECTION¶

Number of timesteps a powerline disconnected for security motives (for example due to NB_TIMESTEP_POWERFLOW_ALLOWED or HARD_OVERFLOW_THRESHOLD) will remain disconnected. It’s set to 10 timestep by default.

Type:: int

NB_TIMESTEP_COOLDOWN_LINE¶

When someone acts on a powerline by changing its status (connected / disconnected) this number indicates how many timesteps the grid2op.Agent.BaseAgent has to wait before being able to modify this status again. For examle, if this is 1, this means that an BaseAgent can act on status of a powerline 1 out of 2 time step (1 time step it acts, another one it cools down, and the next one it can act again). Having it at 0 it equivalent to deactivate this feature (default).

Type:: int

NB_TIMESTEP_COOLDOWN_SUB¶

When someone changes the topology of a substations, this number indicates how many timesteps the grid2op.Agent.BaseAgent has to wait before being able to modify the topology on this same substation. It has the same behaviour as Parameters.NB_TIMESTEP_LINE_STATUS_REMODIF. To deactivate this feature, put it at 0 (default).

Type:: int

HARD_OVERFLOW_THRESHOLD¶

If a the powerflow on a line is above HARD_OVERFLOW_THRESHOLD * thermal limit (and Parameters.NO_OVERFLOW_DISCONNECTION is set to False) then it is automatically disconnected, regardless of the number of timesteps it is on overflow). This is called a “hard overflow”. This is expressed in relative value of the thermal limits, for example, if for a powerline the thermal_limit is 150 and the HARD_OVERFLOW_THRESHOLD is 2.0, then if the flow on the powerline reaches 2 * 150 = 300.0 the powerline the powerline is automatically disconnected.

Type:: float

SOFT_OVERFLOW_THRESHOLD¶

New in version 1.9.3.

Threshold above which delayed protection are triggered. A line with its current bellow SOFT_OVERFLOW_THRESHOLD * thermal_limit then nothing happens. If it’s above the delay start. And if it’s above SOFT_OVERFLOW_THRESHOLD * thermal_limit for more than NB_TIMESTEP_OVERFLOW_ALLOWED consecutive steps.

Type:: float

ENV_DC¶

Whether or not making the simulations of the environment in the “direct current” approximation. This can be usefull for early training of agent, as this mode is much faster to compute than the corresponding “alternative current” powerflow. It is also less precise. The default is False

Type:: bool

FORECAST_DC¶

DEPRECATED. Please use the “change_forecast_param” function of the environment Whether to use the direct current approximation in the grid2op.Observation.BaseObservation.simulate() method. Default is False. Setting FORECAST_DC to True can speed up the computation of the simulate function, but will make the results less accurate.

Type:: bool

MAX_SUB_CHANGED¶

Maximum number of substations that can be reconfigured between two consecutive timesteps by an grid2op.Agent.BaseAgent. Default value is 1.

Type:: int

MAX_LINE_STATUS_CHANGED¶

Maximum number of powerlines statuses that can be changed between two consecutive timesteps by an grid2op.Agent.BaseAgent. Default value is 1.

Type:: int

IGNORE_MIN_UP_DOWN_TIME¶

Whether or not to ignore the attributes gen_min_uptime and gen_min_downtime. Basically setting this parameter to True

Type:: bool

LIMIT_INFEASIBLE_CURTAILMENT_STORAGE_ACTION¶

If set to True (NOT the default) the environment will automatically limit the curtailment / storage actions that otherwise would lead to infeasible state.

For example the maximum ramp up of generator at a given step is 100 MW / step ( ie you can increase the production of these generators of maximum 100 MW at this step) but if you cumul the storage action and the curtailment action, you ask + 110 MW at this step (for example you curtail 100MW of renewables).

In this example, if param.LIMIT_INFEASIBLE_CURTAILMENT_ACTION is False (default) this is a game over. If it’s True then the curtailment action is limited so that it does not exceed 100 MW.

Setting it to True might help the learning of agent using redispatching.

If you want a similar behaviour, when you don’t have access to the parameters of the environment, you can have a look at grid2op.Aciton.BaseAction.limit_curtail_storage().

Note

This argument and the grid2op.Action.BaseAction.limit_curtail_storage() have the same objective: prevent an agent to do some curtailment too strong for the grid.

When using this parameter, the environment will do it knowing exactly what will happen next (: its a bit “cheating”) and limit exactly the action to exactly right amount.

Using grid2op.Aciton.BaseAction.limit_curtail_storage() is always feasible, but less precise.

Type:: bool

INIT_STORAGE_CAPACITY¶

Between 0. and 1. Specify, at the beginning of each episode, what is the storage capacity of each storage unit. The storage capacity will be expressed as fraction of storage_Emax. For example, if INIT_STORAGE_CAPACITY is 0.5 then at the beginning of every episode, all storage unit will have a storage capacity of 0.5 * storage_Emax. By default: 0.5

Type:: float

ACTIVATE_STORAGE_LOSS¶

You can set it to False to not take into account the loss in the storage units. This deactivates the “loss amount per time step” (storage_loss) and has also the effect to set to do as if the storage units were perfect (as if storage_charging_efficiency=1. and storage_discharging_efficiency=1..

NB it does as if it were the case. But the parameters storage_loss, storage_charging_efficiency and storage_discharging_efficiency` are not affected by this.

Default: True

Type:: bool

ALARM_BEST_TIME¶

Number of step for which it’s best to send an alarm BEFORE a game over

Type:: int

ALARM_WINDOW_SIZE¶

Number of steps for which it’s worth it to give an alarm (if an alarm is send outside of the window [ALARM_BEST_TIME - ALARM_WINDOW_SIZE, ALARM_BEST_TIME + ALARM_WINDOW_SIZE] then it does not grant anything

Type:: int

ALERT_TIME_WINDOW¶

Number of steps for which it’s worth it to give an alert after an attack. If the alert is sent before, the assistant score doesn’t take into account that an alert is raised.

Type:: int

MAX_SIMULATE_PER_STEP¶

Maximum number of calls to obs.simuate(…) allowed per step (reset each “env.step(…)”). Defaults to -1 meaning “as much as you want”.

Type:: int

MAX_SIMULATE_PER_EPISODE¶

Maximum number of calls to obs.simuate(…) allowed per episode (reset each “env.simulate(…)”). Defaults to -1 meaning “as much as you want”.

Type:: int

Methods:

`check_valid`()	check the parameter is valid (ie it checks that all the values are of correct types and within the correct range.
`from_json`(json_path)	Create instance of a Parameters from a path where is a json is saved.
`init_from_dict`(dict_)	Initialize the object given a dictionary.
`init_from_json`(json_path)	Set member attributes from a json file
`to_dict`()	Serialize all the _parameters as a dictionnary; Useful to write it in json format.

check_valid()[source]¶

check the parameter is valid (ie it checks that all the values are of correct types and within the correct range.

Raises:: An exception if the parameter is not valid –

staticmethod from_json(json_path)[source]¶

Create instance of a Parameters from a path where is a json is saved.

Parameters:: json_path (str) – The complete (ie. path + filename) where the json file is located.
Returns:: res – The _parameters initialized
Return type:: Parameters

init_from_dict(dict_)[source]¶

Initialize the object given a dictionary. All keys are optional. If a key is not present in the dictionary, the default parameters is used.

Parameters:: dict (dict) – The dictionary representing the parameters to load.

init_from_json(json_path)[source]¶

Set member attributes from a json file

Parameters:: json_path (str) – The complete (ie. path + filename) where the json file is located.

to_dict()[source]¶

Serialize all the _parameters as a dictionnary; Useful to write it in json format.

Returns:: res – A representation of these _parameters in the form of a dictionnary.
Return type:: dict

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

Still trouble finding the information ? Do not hesitate to send a github issue about the documentation at this link: Documentation issue template