-
Notifications
You must be signed in to change notification settings - Fork 8
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
DC security analysis: remove call to sensitivity API #927
Conversation
Signed-off-by: Anne Tilloy <[email protected]>
@@ -238,144 +63,160 @@ private List<OperatorStrategyResult> createOperatorStrategyResults(DcSecurityAna | |||
LfTopoConfig topoConfig = new LfTopoConfig(); | |||
findAllSwitchesToOperate(network, actions, topoConfig); | |||
|
|||
// try to find all pst to retain because involved in pst actions | |||
// try to find all ptc to retain because involved in ptc actions | |||
findAllPtcToOperate(actions, topoConfig); |
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.
@Hadrien-Godard indeed maybe we have to add RTC to operate if DC security analysis is used as a fall back. I think that actions are not going to be filtered and we can fall in issues.
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Anne Tilloy <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
@@ -1887,7 +1876,7 @@ void testDcBusBarSectionContingency() { | |||
assertEquals(433.012, preContingencyNetworkResult.getBranchResult("L2").getI1(), LoadFlowAssert.DELTA_I); | |||
|
|||
assertEquals(866.025, getPostContingencyResult(result, "BBS1").getNetworkResult().getBranchResult("L2").getI1(), LoadFlowAssert.DELTA_I); | |||
assertEquals(Double.NaN, getPostContingencyResult(result, "BBS1").getNetworkResult().getBranchResult("L1").getI1(), LoadFlowAssert.DELTA_I); | |||
// assertEquals(Double.NaN, getPostContingencyResult(result, "BBS1").getNetworkResult().getBranchResult("L1").getI1(), LoadFlowAssert.DELTA_I); |
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.
Now, DC is conformed to AC computation: no branch result for a disabled line at both side. So the line test has to be removed.
Signed-off-by: Anne Tilloy <[email protected]>
@@ -2350,12 +2338,12 @@ void testAcceptableDurations() { | |||
SecurityAnalysisResult result2 = runSecurityAnalysis(network, contingencies.getContingencies(network), Collections.emptyList(), securityAnalysisParameters); | |||
|
|||
LimitViolation violation4 = new LimitViolation("NHV1_NHV2_2", null, LimitViolationType.CURRENT, "permanent", | |||
2147483647, 900.0, 1.0F, 911.605688194146412890625, TwoSides.ONE); | |||
2147483647, 899.9999999999999, 1.0F, 911.6056881941461, TwoSides.ONE); |
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.
899.99999999 is weird...
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
Signed-off-by: Geoffroy Jamgotchian <[email protected]>
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Yes. Issues are:
What kind of change does this PR introduce?
A big code sharing with AC security analysis, but:
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?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Other information:
i
in final state!