-
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
Partial Failure and completeData #1256
Conversation
Signed-off-by: CHEN Roxane <[email protected]>
Signed-off-by: CHEN Roxane <[email protected]>
Signed-off-by: CHEN Roxane <[email protected]>
...src/main/java/com/powsybl/openrao/searchtreerao/castor/algorithm/CastorSecondPreventive.java
Outdated
Show resolved
Hide resolved
...s/src/test/java/com/powsybl/openrao/sensitivityanalysis/SystematicSensitivityResultTest.java
Show resolved
Hide resolved
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'm not sure this fixes the case where N succeeds and all N-1 fail (should give partial failure, currently gives failure, because of line 84 of SystematicSensitivityResult
For me this case is handled by the line 89. If N succeeds this.status is set to success after line 89 and and keeps this value even if all N-1 fail. So in the end we have anyContingencyFailure = true and nStateResult.status = SUCCESS -> this .status is set to PARTIAL_FAILURE as it should ? |
can you try to add a unit test to test it out ? |
Signed-off-by: CHEN Roxane <[email protected]>
Signed-off-by: CHEN Roxane <[email protected]>
Signed-off-by: CHEN Roxane <[email protected]>
Case already tested in testPartialContingencyFailures() in SystematicSensitivityResultTest. |
Signed-off-by: CHEN Roxane <[email protected]>
Signed-off-by: CHEN Roxane <[email protected]>
done |
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Fixes #1238
What kind of change does this PR introduce?
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: