CGMES: remove extension for Control Areas, use IIDM Area

[zamarrenolm]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Does this PR already have an issue describing the problem?

What kind of change does this PR introduce?

Update

What is the current behavior?

Information from CGMES control areas is stored using an extension to the Network Model (CgmesControlArea).

What is the new behavior (if this is a feature change)?
Information from CGMES control areas is stored using native IIDM objects of class Area.
CGMES pTolerance attribute is stored as a property.
The ENTSO-E attribute IdentifiedObject.energyIdentCodeEic is stored as an alias.

For assembled models (CGM), the new behaviour has support for tie flows of a control area located at the boundary point of tie lines

Does this PR introduce a breaking change or deprecate an API?

• Yes
• No

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Previously, during export, if the CgmesControlArea extension was not present in the exported network, a new one was created and a control area representing the whole network was added to it, with the terminals of all dangling lines defined as its tie flows. As a result, the CGMES export always had a control area of type interchange.

After this PR, no control area is automatically created during export. The export process itself will not add, remove or change the attributes of the objects in the IIDM model.

If the user wants to define a control area interchange based on the whole network, it can do it programmatically using the following line of code:

new CgmesExport().createDefaultControlAreaInterchange(network);

It is located in the CgmesExport exporter because the creation of a default area involves potential access to reference data (boundaries) and using some export parameters that the user may have already configured. The relevant data: the sourcing actor (that determines its region and the corresponding EIC code), the consideration of boundary nodes (and associated tie flows) as AC or DC. Also, the user can provide some of the parameters explicitly, if needed. As an example, including the final call to CGMES export:

Properties exportParams = new Properties();
exportParams.put(CgmesImport.BOUNDARY_LOCATION, "....");
exportParams.put(CgmesExport.NAMING_STRATEGY, NamingStrategyFactory.CGMES);

new CgmesExport().createDefaultControlAreaInterchange(network, exportParams);
network.write("CGMES", exportParams, outputPath);

Other information:

• Check if the balancing adjustment mechanism has to be updated (in powsybl-entsoe) and adapt it if needed
• Adapt UCTE import/export

[olperr1]

I think that we should support at least the reading (ideally also the writing) of this extension and map it on IIDM Areas. This will allow to read previously exported IIDM without losing data.

I will write a compatibility SerDe handling it.

[olperr1]

The PR is here: #3298

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
88.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud