You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During security analyses, we cannot detect when a specific limit is almost reached.
The default LimitViolationDetector can be configured to support a limit reduction, but this reduction is applied to every limit.
For instance, we can configure the security analysis to return limit violations when the current is greater than 95% of the limit value, but it applies to all the limits of all the network elements, and thus we can not configure the reduction to be 90% for a specific branch and 100% for all the other branches.
Describe the expected behavior
I. Description
General description
During security analyses, it should be possible to apply different limit reductions depending on several criteria:
the limit type (current, active power or apparent power)
the use cases: for monitoring only or for actions
the contingency context (pre-contingency, after a specific contingency or after all contingencies, ...)
concerning specific network elements (branches, three windings transformers, ...), which could be described by the following criteria:
a set of their ids
their countries
their nominal voltages
their limit characteristics:
the limit type: permanent or temporary
their acceptable duration (for temporary limits)
equal to a specific value
inside an interval.
These criteria can be cumulative (several can be used at the same time to define a limit reduction).
Because a limit can validate the criteria of several limit reductions, the order the limit reductions are declared is important. We will consider that the limit reduction to apply for a limit is the last encountered when reading them from start to end.
Note that these reductions are taken into account when determining the action to apply during security analyses with remedial acitons. For instance, if for a branch the reduced limits are violated but not the original limits and if a remedial action was defined, this one will be applied.
Criteria details
1. Limit type
The type of the limits on which to apply the reduction must be specified (mandatory item). Types to support are:
CURRENT: for current limits;
ACTIVE_POWER: for active power limits;
APPARENT_POWER: for apparent power limits.
2. Use cases (Monitoring or action)
The reduction may applies:
for monitoring only: when a limit is associated with an action and a reduction is applied for monitoring only, if the encountered value is between the reduced limit value and the original limit value, the action should not be applied;
for action: when a limit is associated with an action and a reduction is applied for action, if the encountered value is between the reduced limit value and the original limit value, the action should be applied.
This behavior will be described as a boolean monitoringOnly. When it is true, the 1. case is used, else the 2..
3. Contingency context
Zero or one contingency context can be specified. It contains:
a type among:
ALL: corresponding to all contingencies and pre-contingency situations;
NONE: corresponding to pre-contingency situations;
SPECIFIC: corresponding to a specific contingency situation;
ONLY_CONTINGENCIES: corresponding to all contingency situations (without the pre-contingency one).
and when the type is SPECIFIC, the id of the contingency.
When no contingency context is present, the default is to use the ALL policy.
4. Network elements
We can define the network elements whose limits will be affected by the limit reductions in using several criteria:
a set of the network elements' ids
one or two countries (respectively for elements with one or two substations)
their nominal voltages, by defining an intervals for each of the voltage levels
If no network elements is specified, the limit reduction applies to all of them.
5. Limit duration characteristics
Zero or several duration criteria can be specified. Each one contains:
a type among:
PERMANENT: corresponding to permanent limits only;
TEMPORARY: corresponding to temporary limits only.
and when the type is TEMPORARY, one of the following options to restrict them according to their acceptable duration:
ALL: to select all temporary limits, regardless their acceptable duration;
EQUALITY: to select the temporary limits whose acceptable duration is equal to a specified value, with:
value: the said value.
INTERVAL: to select the temporary limits whose acceptable duration is within an interval, with:
lowBound and highBound: minimum and maximum duration, each can be null;
lowClosed and highClosed: is the interval open (false) or closed (true) on respectively the lower and the upper boundaries? This attribute is facultative if the corresponding bound value is null.
When no duration criteria are present, the reduction should be applied to all permanent and temporary limits.
When several duration criteria are specified, the limit reductions applies to each one. For instance, if both criteria PERMANENT and (TEMPORARY ; EQUALITY ; 600) are defined, the limit reduction will apply to permanent limits and 600s limits.
Point of attention
Having two limits L1 and L2 on the same network element, if L1 has a smaller acceptable duration, we expect L1 to have a higher value than L2.
After limit reductions application, the value of L1 may be lower than the one of L2.
For instance, with the following limits on a line (ordered by ascending values):
L2 : acceptable duration = 20min. ; value = 90MW
L1 : acceptable duration = 1min. ; value = 100MW
and the following limitReduction:
LR : limitsTime=60 ; ratio = 0.8
After the application of the limit reductions, we have the following limits:
L1' : acceptable duration = 1min. ; value = 80MW
L2 : acceptable duration = 20min. ; value = 90MW
This could lead to problems with the actual code (see for instance LimitViolationUtils.getOverload(LoadingLimits, double, float)).
For now, we will ignore the presence à L2 and only consider L1' in our algorithms. When retrieving the limits of an element, a pre-processing should thus be done to order to work only with the limits to consider.
Application
API update
These limit reduction definitions will be added as a new parameter of SecurityAnalysis.Runner.runAsync(…) and of SecurityAnalysisProvider.run(…).
Using these data
Concept
During the analysis, when the limits of a network element are examined, the reductions must apply. The analysis must then work on an altered copy of the original limits, obtained in applying the limit reductions and in removing the unwanted limits (see section "Point of attention").
Important note: the limits in the network must NOT be modified. (Since the limit reductions are not the same for every contingency context, it will be difficult anyway to determine the values to use.)
When limit violation filters and limit reductions are both defined, the filter should have the prevalence. For instance, if the filter is defined with a minimum base voltage of 90kV and if a current limit reduction is defined for a 63kV line, no violations must be detected, regardless of the line's current. In load flow implementations where the filters are applied before detecting the violations (such as powsybl-open-loadflow), the reductions should not be applied for an identifiable if a filter excludes it.
Utility classes
To compute the reduced limits, a new utility object, a ReducedLimitsComputer, will be created. Different implementations will be available:
a "no reduction" one, which will juste return the original limits without applying any reductions;
an abstract one, taking a generic parameter F, which will process the limit reduction definitions and compute the reduced limits of objects of type F;
an implementation of this abstract class, working with IIDM network elements.
ReducedLimitsComputer objects will have a method <T> T getLimitsWithAppliedReduction(F networkElement, ThreeSides side, LimitType limitType)
with:
T: the type of the limits;
networkElement: the type of the network element to process;
side: the side of the network element;
limitType: the limit type (ACTIVE_POWER, CURRENT...).
The reduction definitions will be used to create this object
NB: The studied network element is handed over via an interface.
Adapters will be implemented to turn existing network element representations (for example IIDM) into implementations of the NetworkElementInterface. This interface should contain methods to retrieve the following data from the network element:
its id;
its country(ies);
its voltage level(s).
This is a necessary step to allow users to use the getLimitsWithAppliedReduction in an IIDM context or in an OLF context (or in another context).
These classes already exist in the contingency-api module.
Equipment criteria
Similar criteria already exist to specify contingency lists, in the contingency-api module. Some code may probably be shared between these two functionalities (see the content of com.powsybl.contingency.contingency.list.criterion and the corresponding (de)serialization - CriterionSerializer and CriterionDeserializer).
In this example, the limit reductions defined are:
1st:
Concerns current limits
For action use case
After the contingency "contingencyId1"
For:
all the 400kV lines between France (FR) and Belgium (BE)
all the German (DE) 220kV / 110kV two windings transformers
For every limit (permanent and temporary)
Value of the reduction: 0.8
2nd:
Concerns current limits
For monitoring only use case
In pre-contingency situation
For "line-1" and "transfo-2"
For the temporary limits with an acceptable duration:
= 7200s
in [1200 ; 6000[ s
<= 600s
Value of the reduction: 0.7
Describe the motivation
No response
Extra Information
For the contingency descriptions, PowSyBl has a notion of ContingencyContext, which is used for sensitivity factors description and in the operator strategies. It proposes the 3 cases:
ContingencyContextType.ALL;
ContingencyContextType.NONE;
ContingencyContextType.SPECIFIC.
But it doesn't already support the ONLY_CONTINGENCIES. This policy should be added.
Regarding the previous point, the support of the ONLY_CONTINGENCIES policy should be also added in powsybl-open-loadflow.
The text was updated successfully, but these errors were encountered:
Describe the current behavior
During security analyses, we cannot detect when a specific limit is almost reached.
The default
LimitViolationDetector
can be configured to support a limit reduction, but this reduction is applied to every limit.For instance, we can configure the security analysis to return limit violations when the current is greater than 95% of the limit value, but it applies to all the limits of all the network elements, and thus we can not configure the reduction to be 90% for a specific branch and 100% for all the other branches.
Describe the expected behavior
I. Description
General description
During security analyses, it should be possible to apply different limit reductions depending on several criteria:
These criteria can be cumulative (several can be used at the same time to define a limit reduction).
Because a limit can validate the criteria of several limit reductions, the order the limit reductions are declared is important. We will consider that the limit reduction to apply for a limit is the last encountered when reading them from start to end.
Note that these reductions are taken into account when determining the action to apply during security analyses with remedial acitons. For instance, if for a branch the reduced limits are violated but not the original limits and if a remedial action was defined, this one will be applied.
Criteria details
1. Limit type
The type of the limits on which to apply the reduction must be specified (mandatory item). Types to support are:
CURRENT
: for current limits;ACTIVE_POWER
: for active power limits;APPARENT_POWER
: for apparent power limits.2. Use cases (Monitoring or action)
The reduction may applies:
for monitoring only: when a limit is associated with an action and a reduction is applied for monitoring only, if the encountered value is between the reduced limit value and the original limit value, the action should not be applied;
for action: when a limit is associated with an action and a reduction is applied for action, if the encountered value is between the reduced limit value and the original limit value, the action should be applied.
This behavior will be described as a boolean
monitoringOnly
. When it istrue
, the1.
case is used, else the2.
.3. Contingency context
Zero or one contingency context can be specified. It contains:
ALL
: corresponding to all contingencies and pre-contingency situations;NONE
: corresponding to pre-contingency situations;SPECIFIC
: corresponding to a specific contingency situation;ONLY_CONTINGENCIES
: corresponding to all contingency situations (without the pre-contingency one).SPECIFIC
, the id of the contingency.When no contingency context is present, the default is to use the
ALL
policy.4. Network elements
We can define the network elements whose limits will be affected by the limit reductions in using several criteria:
If no network elements is specified, the limit reduction applies to all of them.
5. Limit duration characteristics
Zero or several duration criteria can be specified. Each one contains:
PERMANENT
: corresponding to permanent limits only;TEMPORARY
: corresponding to temporary limits only.TEMPORARY
, one of the following options to restrict them according to their acceptable duration:ALL
: to select all temporary limits, regardless their acceptable duration;EQUALITY
: to select the temporary limits whose acceptable duration is equal to a specified value, with:value
: the said value.INTERVAL
: to select the temporary limits whose acceptable duration is within an interval, with:lowBound
andhighBound
: minimum and maximum duration, each can be null;lowClosed
andhighClosed
: is the interval open (false
) or closed (true
) on respectively the lower and the upper boundaries? This attribute is facultative if the corresponding bound value isnull
.When no duration criteria are present, the reduction should be applied to all permanent and temporary limits.
When several duration criteria are specified, the limit reductions applies to each one. For instance, if both criteria
PERMANENT
and (TEMPORARY
;EQUALITY
; 600) are defined, the limit reduction will apply to permanent limits and 600s limits.Point of attention
Having two limits
L1
andL2
on the same network element, ifL1
has a smaller acceptable duration, we expectL1
to have a higher value thanL2
.After limit reductions application, the value of
L1
may be lower than the one ofL2
.For instance, with the following limits on a line (ordered by ascending values):
L2
: acceptable duration = 20min. ; value = 90MWL1
: acceptable duration = 1min. ; value = 100MWand the following limitReduction:
LR
: limitsTime=60 ; ratio = 0.8After the application of the limit reductions, we have the following limits:
L1'
: acceptable duration = 1min. ; value = 80MWL2
: acceptable duration = 20min. ; value = 90MWThis could lead to problems with the actual code (see for instance
LimitViolationUtils.getOverload(LoadingLimits, double, float)
).For now, we will ignore the presence à
L2
and only considerL1'
in our algorithms. When retrieving the limits of an element, a pre-processing should thus be done to order to work only with the limits to consider.Application
API update
These limit reduction definitions will be added as a new parameter of
SecurityAnalysis.Runner.runAsync(…)
and ofSecurityAnalysisProvider.run(…)
.Using these data
Concept
During the analysis, when the limits of a network element are examined, the reductions must apply. The analysis must then work on an altered copy of the original limits, obtained in applying the limit reductions and in removing the unwanted limits (see section "Point of attention").
Important note: the limits in the network must NOT be modified. (Since the limit reductions are not the same for every contingency context, it will be difficult anyway to determine the values to use.)
When limit violation filters and limit reductions are both defined, the filter should have the prevalence. For instance, if the filter is defined with a minimum base voltage of 90kV and if a current limit reduction is defined for a 63kV line, no violations must be detected, regardless of the line's current. In load flow implementations where the filters are applied before detecting the violations (such as powsybl-open-loadflow), the reductions should not be applied for an identifiable if a filter excludes it.
Utility classes
To compute the reduced limits, a new utility object, a
ReducedLimitsComputer
, will be created. Different implementations will be available:F
, which will process the limit reduction definitions and compute the reduced limits of objects of typeF
;ReducedLimitsComputer
objects will have a method<T> T getLimitsWithAppliedReduction(F networkElement, ThreeSides side, LimitType limitType)
with:
T
: the type of the limits;networkElement
: the type of the network element to process;side
: the side of the network element;limitType
: the limit type (ACTIVE_POWER, CURRENT...).The reduction definitions will be used to create this object
NB: The studied network element is handed over via an interface.
Adapters will be implemented to turn existing network element representations (for example IIDM) into implementations of the
NetworkElementInterface
. This interface should contain methods to retrieve the following data from the network element:This is a necessary step to allow users to use the
getLimitsWithAppliedReduction
in an IIDM context or in an OLF context (or in another context).II. Concept of code
Classes
Limit reduction definitions
Contingency contexts
These classes already exist in the
contingency-api
module.Equipment criteria
Similar criteria already exist to specify contingency lists, in the
contingency-api
module. Some code may probably be shared between these two functionalities (see the content ofcom.powsybl.contingency.contingency.list.criterion
and the corresponding (de)serialization -CriterionSerializer
andCriterionDeserializer
).Limit duration criteria
General types and interface
Permanent duration criterion
Temporary duration criteria
(De)serialization
The limit reductions should be serializable and deserializable in JSON.
Here is an example of a JSON serialized limit reduction list:
In this example, the limit reductions defined are:
Describe the motivation
No response
Extra Information
For the contingency descriptions, PowSyBl has a notion of
ContingencyContext
, which is used for sensitivity factors description and in the operator strategies. It proposes the 3 cases:ContingencyContextType.ALL
;ContingencyContextType.NONE
;ContingencyContextType.SPECIFIC
.But it doesn't already support the
ONLY_CONTINGENCIES
. This policy should be added.Regarding the previous point, the support of the
ONLY_CONTINGENCIES
policy should be also added inpowsybl-open-loadflow
.The text was updated successfully, but these errors were encountered: