[CGMES] Less internal connections created at import

[flo-dup]

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?
No

What kind of change does this PR introduce?
Feature

What is the current behavior?
Each connectable and switch is created with two nodes at each end, one for the cim:ConnectivityNode, one for the cim:Terminal. The two nodes are connected with an InternalConnection. This leads to a verbose iidm file with an excessive number of InternalConnections.

What is the new behavior (if this is a feature change)?

When the configuration is the following:

• iidm.import.cgmes.create-fictitious-switches-for-disconnected-terminals-mode is NEVER (default value is ALWAYS)
• and iidm.import.cgmes.create-busbar-section-for-every-connectivity-node is false (which is the default value)

The InternalConnection is created only if needed:

• if there's only one Connectable at the ConnectivityNode, no InternalConnection
• if there are two Connectables at the ConnectivityNode, only one InternalConnection is created, for the first Connectable encountered (instead of one for each)
• if there are more than two Connectables, one InternalConnection is created between each terminal and the ConnectivityNode, except for the BusbarSection case:
  • if there's exactly one BusbarSection among the connectables, the InternalConnection are created between this BusbarSection and the other connectables
  • if there's more than one BusbarSection (does not make so much sense, but exists in real data), the InternalConnections are created between the first BusbarSection and all the other Connectables, including the other BusbarSections.

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

• Yes
• No

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[zamarrenolm]

Just one quick consideration: could all these rules/simplification of the underlying connectivity model be moved to a post-processor after import (or a network modification). This way it could be useful for all importers, in a centralised way, and we should not need to consider them in every importer that have to handle. For example, recent versions of PSSE (35 and later) support node/breaker models where we could face similar problems.

[flo-dup]

Just one quick consideration: could all these rules/simplification of the underlying connectivity model be moved to a post-processor after import (or a network modification). This way it could be useful for all importers, in a centralised way, and we should not need to consider them in every importer that have to handle. For example, recent versions of PSSE (35 and later) support node/breaker models where we could face similar problems.

Thanks for pointing out that similarity with PSSE! But we should rather centralize it in a utility method. Post-processing is not the good way to go I think (in terms of performance, robustness, and readability). That's at the cost of handling the utility method call (and map building beforehand) in each importer, and having an abstraction which allows it, sure. If that's not possible, I think we should rather duplicate the logic than putting it in a common postprocessing.

[flo-dup]

Tested on ENTSO-E CGMES sample data SmallGrid/NodeBreaker

	Without this PR	With this PR
iidm export file size	630ko	450ko
internal connections	2834	136
read time on my laptop (averaged over 100 iterations)	0.81094s	0.80416s

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[rcourtier]

Functionnally, this parameter shouldn't change the result.
Since you didn't provide a SSH file, all terminals are considered connected.

[rcourtier]

You don't have to systematically create a node for the terminal and an internal connection between the terminal's node and the connectivitynode's node. You could do it only if needed, that is if 2 or more connected non-switch equipments share that terminal's connectivity node.

[rcourtier]

To simplify the import, you may use a method from ConversionUtil class in com.powsybl.cgmes.conversion.test package:

public static Network readCgmesResources(Properties properties, String dir, String... files)

That may be especially handy when you need to read several files (like EQ and SSH instance).