Fix field Model.DependentOn in CGMES export

[colinepiloquet]

Please check if the PR fulfills these requirements

• [x] 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?

Bug fix: the dependencies exported in the field Model.DependentOn are wrong. I have: For CGMES 2.4.15: EQ -> EQBD TP -> EQ SSH -> EQ SV -> TP, TPBD, SSH

For CGMES 3.0: EQ -> EQBD TP -> EQ, TPBD SSH -> EQ SV -> TP, TPBD, SSH, EQ

What is the current behavior?

Some dependencies are missing and some are too much

What is the new behavior (if this is a feature change)? The dependencies match what is written above

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

• [ ] Yes
• [X] No

[colinepiloquet]

@nemanja-st, @zamarrenolm, can you please double check that I am not wrong. I checked for CGMES 2.4.15 with the export and it seems correct but the link between SV and EQ in 3.0 is not clear for me.

[jeandemanged]

Doesn't sound right, looking at CGMES 3.0 UML + these two videos: ENTSO-E CGMES 3.0 Boundary Profiles Instance Data and ENTSO-E CGMES 3.0 Modelling styles (Bus-Branch and Node-Breaker)

• EQBD in CGMES 3.0 has been deprecated and is now aligned with "plain/regular" EQ
• TPBD does not exist anymore in CGMES 3.0, all IGMs are required to be modeled using ConnectivityNodes, independently whether Bus/Breaker or Node/Breaker.
• EQ in CGMES 3.0 defines eu:BoundaryPoint and association eu:BoundaryPoint.ConnectivityNode

So it is weird that we still see EQBD and TPBD around about CGMES 3.0

I think it is easier to understand if we refer to model instances instead of model profiles used. EQBD looks like a boundary profile is used, but for CGMES 3.0 should refer instead to a "Boundary EQ model instance".

Looking at CGMES 3.0 CAS Test Configuration v3.0.2 for Microgrid

For IGMs (BE and NL):

• IGM EQ dependent on Boundary EQ
• IGM SSH dependent on IGM EQ
• IGM TP dependent on IGM SSH
• IGM SV dependent on IGM TP

For CGM:

• BE and NL: IGM EQ dependent on Boundary EQ
• BE and NL: IGM SSH dependent on IGM EQ
• CGM TP dependent on BE IGM SSH + NL IGM SSH
• CGM SV dependent on CGM TP

[nemanja-st]

2.4.15 references look ok, this is from QoCDC document:

3.0, I have some profiles from 2022 and there EQBD is a separate profile.

From the video Damien shared, suggestion might be that boundary data is in Common Data, which is not yet finished. In MetadataAndHeaderDataExchangeSpecification_v2.3.0 there are examples of BaseVoltage reference, but nothing regarding boundary points.

In Boundary_and_reference_data_exchange_specification_v1.0 there is a link to example boundary data, but I don't have access to it ModularBoundaryPerMasBorderSeparateRefData.zip

[annetill]

Thanks @jeandemanged and @nemanja-st for your answers! A little bit of pragmatism: we need a (quick) fix for CGMES 2.4.15 because our network cannot be uploaded in operation. We are going to open a new PR with the fixes only for that version. Okay?

[jeandemanged]

Thanks @jeandemanged and @nemanja-st for your answers! A little bit of pragmatism: we need a (quick) fix for CGMES 2.4.15 because our network cannot be uploaded in operation. We are going to open a new PR with the fixes only for that version. Okay?

sounds great, thanks

[sonarqubecloud[bot]]

Quality Gate passed

Kudos, no new issues were introduced!

0 New issues
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[zamarrenolm]

Just for reference and complete the discussion, the dependencies from ENTSO-E test configurations in 2.4.15 do not strictly follow the rules in the QoCDC.

As an example one can look at MicroGrid BaseCase (bus/branch): the IMG TP file (for BE for example) depends explicitly on TP_BD and EQ_BD, in addition to the IGM EQ instance file.

The dependency of TP_BD makes sense, since the TP file for the IMG must contain references to Topological Nodes defined in the boundary TP file: the IMG is responsible for modelling its part of the lines at boundaries, and the corresponding equivalent injections, so in its TP file the IMG has to include to which TN node of the boundary the related terminals point to.

In addition, the QoCDC states (version 3.3.2, section 6.2) that non-required dependencies should be ignored: