Export without topological nodes mapping

[marcosmc]

Please check if the PR fulfills these requirements (please use '[x]' to check the checkboxes, or submit the PR and then click the checkboxes)

• [ ] 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 ? If so, link to this issue using '#XXX' and skip the rest

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

What is the current behavior? (You can also link to an open issue here)

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

Does this PR introduce a breaking change or deprecate an API? If yes, check the following:

• [ ] The Breaking Change or Deprecated label has been added
• [ ] The migration guide has been updated in the github wiki (What changes might users need to make in their application due to this PR?)

Other information:

(if any of the questions/checkboxes don't apply, please delete them entirely)

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
8 Code Smells

95.7% Coverage
0.0% Duplication

[miovd]

@zamarrenolm @marcosmc In this case, do we lose topological mapping? (IDs, etc) I thought we agreed to keep the behavior available for some processes that only export SSH and SV files for example

[zamarrenolm]

@zamarrenolm @marcosmc In this case, do we lose topological mapping? (IDs, etc) I thought we agreed to keep the behavior available for some processes that only export SSH and SV files for example

Moved the PR to draft again while we review these use cases.

[zamarrenolm]

@zamarrenolm @marcosmc In this case, do we lose topological mapping? (IDs, etc) I thought we agreed to keep the behavior available for some processes that only export SSH and SV files for example

Moved the PR to draft again while we review these use cases.

With @miovd, @annetill we have agreed on completely removing persistence of Topological Node identifiers for node/breaker models. For use cases like the one described (user is interested only in SV export), a new TP must be exported to obtain proper references of SV values.

At this point, the user must be aware that the TP export must be requested together with the SV export. Maybe we should consider emitting a warning or trying to enforce TP export in these situations ?

[miovd]

@zamarrenolm @marcosmc In this case, do we lose topological mapping? (IDs, etc) I thought we agreed to keep the behavior available for some processes that only export SSH and SV files for example

Moved the PR to draft again while we review these use cases.

With @miovd, @annetill we have agreed on completely removing persistence of Topological Node identifiers for node/breaker models. For use cases like the one described (user is interested only in SV export), a new TP must be exported to obtain proper references of SV values.

At this point, the user must be aware that the TP export must be requested together with the SV export. Maybe we should consider emitting a warning or trying to enforce TP export in these situations ?

Yes, a warning would be nice! I have another question: if we make two successive CGMES exports, are the TN IDs persistent for node-breaker or are they always re-generated?

[miovd]

Hi @zamarrenolm @marcosmc ! I was just wondering if you have seen my last comment?

Yes, a warning would be nice! I have another question: if we make two successive CGMES exports, are the TN IDs persistent for node-breaker or are they always re-generated?

[zamarrenolm]

Hi @zamarrenolm @marcosmc ! I was just wondering if you have seen my last comment?

Yes, a warning would be nice! I have another question: if we make two successive CGMES exports, are the TN IDs persistent for node-breaker or are they always re-generated?

Sure. We saw your last comment. I am working on adding the warning.

About successive CGMES exports and TN IDs persistence: we use the IIDM bus-breaker (calculated) identifiers as TN identifiers, so they will be the same in successive exports. Also, if you use a naming strategy and you keep the mapping between exports, the final identifiers should be the same, even if they are fixed because they are not valid CGMES.

[sonarqubecloud[bot]]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
6 Code Smells

95.9% Coverage
0.0% Duplication