-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delete Merging View implementation #2612
Conversation
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Don't forget to remove references to the merging view in the website. A quick search gives me the list of artifacts, but there are potential other pages. |
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
@@ -114,22 +113,19 @@ void microGridBaseCaseBEMergingViewNL() { | |||
// Both networks have the same number of dangling lines | |||
assertEquals(nDlBE, nDlNL); | |||
|
|||
Network n = MergingView.create("be-nl", "CGMES"); | |||
n.merge(nl, be); | |||
be.merge(nl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We see here that we have an equivalence now between the merging view and the destructive merge for equipments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this test can be merged with the test above microGridBaseCaseBEMergedWithNL
, they check the same thing now...
compareMerges(tieLineId, assembled, ds1, ds2); | ||
} | ||
|
||
private static void compareMerges(String tieLineId, ReadOnlyDataSource dsAssembled, ReadOnlyDataSource ds1, ReadOnlyDataSource ds2) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tie lines in the merging view and in the destructive merge are now equivalent. These tests can be deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly okay for me, one small comment.
Before deleting the merging view, be sure to check that the EMF process is equivalent with sub-networks and the merging view :)
@@ -114,22 +113,19 @@ void microGridBaseCaseBEMergingViewNL() { | |||
// Both networks have the same number of dangling lines | |||
assertEquals(nDlBE, nDlNL); | |||
|
|||
Network n = MergingView.create("be-nl", "CGMES"); | |||
n.merge(nl, be); | |||
be.merge(nl); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this test can be merged with the test above microGridBaseCaseBEMergedWithNL
, they check the same thing now...
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
The merging view is also used in the "powsybl/powsybl-tutorials" repository. |
* Delete merging view iidm implementation. * Clean CGMES tests. --------- Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Maybe issues are related to the merging view (see issues). After the tie lines refactoring, the sub-networks modeling will be the only tool box for CGMES profiles export.
What kind of change does this PR introduce?
The merging view as IIDM implementation is no more available, too risky to use too hard and costly to fix directly.
What is the current behavior?
What is the new behavior (if this is a feature change)?
Does this PR introduce a breaking change or deprecate an API?
Other information: