New contingency list models

[sylvlecl]

• Do you want to request a feature or report a bug?

Feature

• What is the current behavior?

Only one implementation of ContingencyList is proposed by powsybl-core, if we exclude the groovy implementation.

Therefore, we cannot represent as a POJO or as JSON such things as "automatic" list, for example the list of all 400kV lines.

• What is the expected behavior?

The following implementations would be helpful:

1. Multi-list Simply a list of lists.

2. Criterion-based implementation A list based on some filters:

• List of countries to be included
• List of element types to be included
• List of regex on the element IDs, to be included
• List of regex on the element IDs, to be excluded
• List of nominal voltages (or nominal voltage ranges) to be included

3. Multi-identifiers explicit list

In some use cases, we want to use the same list on networks coming from different sources/formats. In order to achieve this, we need to be able to specify alternative identifiers for the same network element. Plus, the identifier cannot always be a simple string: sometimes for a branch we only have the 2 voltage levels and the order. Therefore we could use something like:

{
    "id": "multi-identifiers-contingency",
    "elements" : [
         {
             "type": "LINE",
             "identifiers": [
                  { "type": "id", "id": "LINE1" },
                  { "type": "voltage_levels_and_order", "vl1": "UCTE_VL1",  "vl2": "UCTE_VL2", "order": "1" },
             ]
         }
    ]
}

This describes a contingency on line "LINE1" if it's present in the network, or on the line of order code 1 between "UCTE_VL1" and "UCTE_VL2" else.

• What is the motivation / use case for changing the behavior?

We need to use the same list definition for various networks, with elements being added or removed or renamed from time to time, and from different data sources.

[geofjamg]

We already have this kind of feature in GridSuite, but it has not been shared with PowSyBl. We should refactor what we have done to support what you described in PowSyBl.

[sylvlecl]

About criterion-based lists, I wonder about the possibility of having a more re-usable approach: defining a set of elements or filters of elements is something that could be used for many features, for example scalables etc.

We could have a common model for those sets/filters of network elements, not only related to contingencies definition, that we would re-use here.

We could maybe define a kind of mini-language (not groovy or introspection based) for those filters, that could be supported by some front-end components (think JIRA filters for example), "network query language" or something like that.