Operator strategy notebook¶

This notebook illustrates how to run a security analysis with remedial actions. For a contingency, an operator strategy groups a list of actions and a condition to apply them. This small tutorial is based on a 6 nodes network, called Metrix, that is easily understandable. We are going to simulate contingencies and various operator strategies to show the available features. Network elements can be monitored in pre-contingency state, after a contingency and after each operator strategy.

In [3]:

pip install pypowsybl

Defaulting to user installation because normal site-packages is not writeable
Looking in indexes: https://devin-depot.rte-france.com/repository/pypi-all/simple
Requirement already satisfied: pypowsybl in /home/kuleszahug/.local/lib/python3.8/site-packages (1.4.0.dev1)
Requirement already satisfied: prettytable in /home/kuleszahug/.local/lib/python3.8/site-packages (from pypowsybl) (2.0.0)
Requirement already satisfied: numpy>=1.20.0 in /home/kuleszahug/.local/lib/python3.8/site-packages (from pypowsybl) (1.24.3)
Requirement already satisfied: networkx in /home/kuleszahug/.local/lib/python3.8/site-packages (from pypowsybl) (3.1)
Requirement already satisfied: pandas>=1.3.5 in /home/kuleszahug/.local/lib/python3.8/site-packages (from pypowsybl) (2.0.3)
Requirement already satisfied: python-dateutil>=2.8.2 in /home/kuleszahug/.local/lib/python3.8/site-packages (from pandas>=1.3.5->pypowsybl) (2.8.2)
Requirement already satisfied: pytz>=2020.1 in /home/kuleszahug/.local/lib/python3.8/site-packages (from pandas>=1.3.5->pypowsybl) (2023.3)
Requirement already satisfied: tzdata>=2022.1 in /home/kuleszahug/.local/lib/python3.8/site-packages (from pandas>=1.3.5->pypowsybl) (2023.3)
Requirement already satisfied: setuptools in /home/kuleszahug/.local/lib/python3.8/site-packages (from prettytable->pypowsybl) (69.1.1)
Requirement already satisfied: wcwidth in /home/kuleszahug/.local/lib/python3.8/site-packages (from prettytable->pypowsybl) (0.2.6)
Requirement already satisfied: six>=1.5 in /home/kuleszahug/.local/lib/python3.8/site-packages (from python-dateutil>=2.8.2->pandas>=1.3.5->pypowsybl) (1.16.0)
DEPRECATION: distro-info 0.23ubuntu1 has a non-standard version number. pip 24.1 will enforce this behaviour change. A possible replacement is to upgrade to a newer version of distro-info or contact the author to suggest that they release a version with a conforming version number. Discussion can be found at https://github.com/pypa/pip/issues/12063
DEPRECATION: python-debian 0.1.36ubuntu1 has a non-standard version number. pip 24.1 will enforce this behaviour change. A possible replacement is to upgrade to a newer version of python-debian or contact the author to suggest that they release a version with a conforming version number. Discussion can be found at https://github.com/pypa/pip/issues/12063
Note: you may need to restart the kernel to use updated packages.

In [4]:

import pypowsybl as pp
import pandas as pd
import numpy as np
from pypowsybl._pypowsybl import ConditionType

In [5]:

six_nodes = pp.network.create_metrix_tutorial_six_buses_network()

6 nodes network

In [7]:

six_nodes.get_network_area_diagram()

Out[7]:

NE_poste

</td> <td>380.0 kV / -0.0°</td> </tr> </table>

</foreignObject> <foreignObject id="2-textnode" y="351.67" x="172.45" height="1" width="1">

NO_poste

</td> <td>380.0 kV / 0.0°</td> </tr> </table>

</foreignObject> <foreignObject id="4-textnode" y="-13.45" x="89.94" height="1" width="1">

N_poste

</td> <td>380.0 kV / -0.0°</td> </tr> </table>

</foreignObject> <foreignObject id="6-textnode" y="420.99" x="733.10" height="1" width="1">

SE_poste

</td> <td>380.0 kV / -0.1°</td> </tr> </table>

</foreignObject> <foreignObject id="8-textnode" y="668.10" x="458.46" height="1" width="1">

SO_poste

</td> <td>380.0 kV / 0.0°</td> </tr> </table>

</foreignObject> <foreignObject id="10-textnode" y="787.58" x="813.20" height="1" width="1">

S_poste

</td> <td>380.0 kV / -0.0°</td> </tr> </table>

</foreignObject>

In [8]:

sa = pp.security.create_analysis()

We simulate a contingency on line S_SO_1. When loosing this line, flows are redirected and line S_SO_2 is overloaded. We are going to test various operator strategies to remove the limit violation.

In [9]:

sa.add_single_element_contingency('S_SO_1', 'S_SO_1_contingency')

In [10]:

sa.add_monitored_elements(branch_ids=['S_SO_2', 'SO_NO_1'])

We add a current limit on line S_SO_2

In [11]:

six_nodes.create_operational_limits(pd.DataFrame.from_records(index='element_id', data=[
   {'element_id': 'S_SO_2', 'name': 'permanent_limit', 'element_type': 'LINE', 'side': 'TWO',
    'type': 'CURRENT', 'value': 400,
    'acceptable_duration': np.Inf, 'is_fictitious': False}
 ]))

Detailed topology¶

SO_poste¶

In [12]:

six_nodes.get_single_line_diagram('SO_poste')

Out[12]:

SE_poste¶

In [13]:

six_nodes.get_single_line_diagram('SE_poste')

Out[13]:

Topological remedial actions¶

You have to add all the actions involved in the strategies you want to test. Here, we want to see the effect of opening switches SS1_SS1_DJ_OMN or/and SOO1_SOO1_DJ_OMN: opening only the first one, only the second one or both. Operator strategies have the condition ANY_VIOLATION_CONDITION

In [14]:

sa.add_switch_action(action_id='Switch_SS1_SS1_DJ_OMN_OPEN', switch_id='SS1_SS1_DJ_OMN', open=True)

In [15]:

sa.add_switch_action(action_id='Switch_SOO1_SOO1_DJ_OMN_OPEN', switch_id='SOO1_SOO1_DJ_OMN', open=True)

In [16]:

sa.add_operator_strategy('StrategyOpenSS1_SS1', 'S_SO_1_contingency', ['Switch_SS1_SS1_DJ_OMN_OPEN'], ConditionType.ANY_VIOLATION_CONDITION) 

In [17]:

sa.add_operator_strategy('StrategyOpenSOO1_SOO1', 'S_SO_1_contingency', ['Switch_SOO1_SOO1_DJ_OMN_OPEN'], ConditionType.ANY_VIOLATION_CONDITION) 

In [18]:

sa.add_operator_strategy('StrategyOpenBothSwitchs', 'S_SO_1_contingency', ['Switch_SS1_SS1_DJ_OMN_OPEN', 'Switch_SOO1_SOO1_DJ_OMN_OPEN'], ConditionType.ANY_VIOLATION_CONDITION) 

Redispatch remedial actions¶

An other strategy could be to modify the active power target of some generators, in a way the two modifications compensate (also called re-dispatching). Decreasing active power target of generator SO_G2 and increasing active power of SE_G (closer to loads) could be efficient.

In [19]:

sa.add_generator_active_power_action(action_id='Simple_Redispatch_SO_G2', generator_id='SO_G2', is_relative=True, active_power=-100)
sa.add_generator_active_power_action(action_id='Simple_Redispatch_SE_G', generator_id='SE_G', is_relative=True, active_power=100)

In [20]:

sa.add_operator_strategy('StrategyRedispatch', 'S_SO_1_contingency', ['Simple_Redispatch_SO_G2', 'Simple_Redispatch_SE_G'], ConditionType.ANY_VIOLATION_CONDITION)

Run the security analysis¶

In [21]:

sa_result = sa.run_ac(six_nodes)

Check the results at each steps¶

Pre contingency step¶

We should have no limit violations at the pre contingency state.

In [22]:

sa_result.pre_contingency_result

Out[22]:

PreContingencyResult(, status=CONVERGED, limit_violations=[0])

Post contingency step¶

Then the first contingency trigger the current limit installed on S_SO_2

In [23]:

sa_result.find_post_contingency_result('S_SO_1_contingency')

Out[23]:

PostContingencyResult(contingency_id='S_SO_1_contingency', status=CONVERGED, limit_violations=[1])

In [24]:

sa_result.find_post_contingency_result('S_SO_1_contingency').limit_violations[0]

Out[24]:

LimitViolation(subject_id='S_SO_2', subject_name='', limit_type=CURRENT, limit=400.0, limit_name='permanent', acceptable_duration=2147483647, limit_reduction=1.0, value=419.2577908692318, side=TWO)

We see that the flow is at 419.25.

StrategyOpenSS1_SS1¶

Let's check results for StrategyOpenSS1_SS1 :

In [25]:

 sa_result.operator_strategy_results['StrategyOpenSS1_SS1']

Out[25]:

OperatorStrategyResult(operator_strategy_id='StrategyOpenSS1_SS1', status=CONVERGED, limit_violations=[0])

In [26]:

sa_result.branch_results.loc['S_SO_1_contingency', 'StrategyOpenSS1_SS1', 'S_SO_2']['i2']

Out[26]:

378.3380062100674

We no longer have a limit violation, and we see that flow on S_SO2 is under 400.

StrategyOpenSOO1_SOO1¶

Let's check results for StrategyOpenSOO1_SOO1 :

In [27]:

 sa_result.operator_strategy_results['StrategyOpenSOO1_SOO1']

Out[27]:

OperatorStrategyResult(operator_strategy_id='StrategyOpenSOO1_SOO1', status=CONVERGED, limit_violations=[2])

In [28]:

 sa_result.operator_strategy_results['StrategyOpenSOO1_SOO1'].limit_violations[0]

Out[28]:

LimitViolation(subject_id='SO_NO_1', subject_name='', limit_type=CURRENT, limit=700.0, limit_name="10'", acceptable_duration=1, limit_reduction=1.0, value=1044.4966633667539, side=ONE)

In [29]:

sa_result.operator_strategy_results['StrategyOpenSOO1_SOO1'].limit_violations[1]

Out[29]:

LimitViolation(subject_id='SO_NO_1', subject_name='', limit_type=CURRENT, limit=600.0, limit_name='permanent', acceptable_duration=2147483647, limit_reduction=1.0, value=1044.4966633667539, side=TWO)

We see that we have two new limit violation on SO_NO_1. But still no limit violation on S_SO2

StrategyOpenBothSwitchs¶

Let's check results for StrategyOpenBothSwitchs :

In [30]:

 sa_result.operator_strategy_results['StrategyOpenBothSwitchs']

Out[30]:

OperatorStrategyResult(operator_strategy_id='StrategyOpenBothSwitchs', status=CONVERGED, limit_violations=[2])

In [31]:

sa_result.operator_strategy_results['StrategyOpenSOO1_SOO1'].limit_violations[0]

Out[31]:

LimitViolation(subject_id='SO_NO_1', subject_name='', limit_type=CURRENT, limit=700.0, limit_name="10'", acceptable_duration=1, limit_reduction=1.0, value=1044.4966633667539, side=ONE)

In [32]:

sa_result.operator_strategy_results['StrategyOpenSOO1_SOO1'].limit_violations[1]

Out[32]:

LimitViolation(subject_id='SO_NO_1', subject_name='', limit_type=CURRENT, limit=600.0, limit_name='permanent', acceptable_duration=2147483647, limit_reduction=1.0, value=1044.4966633667539, side=TWO)

We also have some violations on SO_NO_1 but still no violation on S_SO2.

StrategyRedispatch¶

Finally the StrategyRedispatch :

In [33]:

 sa_result.operator_strategy_results['StrategyRedispatch']

Out[33]:

OperatorStrategyResult(operator_strategy_id='StrategyRedispatch', status=CONVERGED, limit_violations=[0])

No more limit violations !

Observe the flow on each step of the analysis¶

To have an overview on the flows on S_SO_2 you can print the whole monitored branche results :

In [34]:

sa_result.branch_results

Out[34]:

			p1	q1	i1	p2	q2	i2	flow_transfer
contingency_id	operator_strategy_id	branch_id
		SO_NO_1	54.531481	-110.016475	174.419119	-53.892618	110.107741	174.419119	NaN
		S_SO_2	-133.377630	85.519336	226.042956	134.297348	-85.366050	226.042956	NaN
S_SO_1_contingency		SO_NO_1	79.418783	-124.999658	210.365186	-78.489460	125.132419	210.365186	NaN
		S_SO_2	-249.100890	153.754036	419.257791	252.264878	-153.226705	419.257791	NaN
	StrategyOpenSS1_SS1	SO_NO_1	92.554967	-133.720643	231.007243	-91.434316	133.880736	231.007243	NaN
	StrategyOpenSS1_SS1	S_SO_2	-226.152625	136.898071	378.338006	228.729139	-136.468652	378.338006	NaN
	StrategyOpenSOO1_SOO1	SO_NO_1	451.041734	-580.734940	1044.496663	-428.131295	584.007860	1044.496663	NaN
	StrategyOpenSOO1_SOO1	S_SO_2	-136.449843	11.254213	199.930622	137.169344	-11.134296	199.930622	NaN
	StrategyOpenBothSwitchs	SO_NO_1	451.154164	-580.693805	1044.548491	-428.241452	583.967049	1044.548491	NaN
	StrategyOpenBothSwitchs	S_SO_2	-125.372880	9.603397	183.434283	125.978547	-9.502452	183.434283	NaN
	StrategyRedispatch	SO_NO_1	59.361506	-124.265369	195.621370	-58.557884	124.380172	195.621370	NaN
	StrategyRedispatch	S_SO_2	-185.947603	155.624090	346.465617	188.108295	-155.263975	346.465617	NaN

In [ ]: