-
Notifications
You must be signed in to change notification settings - Fork 8
Remove network results and violation detection on disabled branches on one side in fast DC Security Analysis #1213
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
Merged
vidaldid-rte
merged 14 commits into
main
from
fix-detection-of-violations-on-disabled-elements-in-fast-dc-sa
Apr 4, 2025
Merged
Remove network results and violation detection on disabled branches on one side in fast DC Security Analysis #1213
vidaldid-rte
merged 14 commits into
main
from
fix-detection-of-violations-on-disabled-elements-in-fast-dc-sa
Apr 4, 2025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
…ed branches on one side Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
Signed-off-by: p-arvy <[email protected]>
p-arvy
commented
Mar 28, 2025
src/main/java/com/powsybl/openloadflow/dc/fastdc/ConnectivityBreakAnalysis.java
Show resolved
Hide resolved
Signed-off-by: p-arvy <[email protected]>
…sabled-elements-in-fast-dc-sa
Signed-off-by: Hadrien <[email protected]>
Hadrien-Godard
previously approved these changes
Apr 2, 2025
vidaldid-rte
previously approved these changes
Apr 3, 2025
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.
Just one minor remark about a comment (about sorting) that should be in the code to explain the purpose and importance of sorting.
…sabled-elements-in-fast-dc-sa
Signed-off-by: p-arvy <[email protected]>
…isabled-elements-in-fast-dc-sa' into fix-detection-of-violations-on-disabled-elements-in-fast-dc-sa
|
vidaldid-rte
approved these changes
Apr 3, 2025
Hadrien-Godard
approved these changes
Apr 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
No.
What kind of change does this PR introduce?
This PR aims to remove network results and limit violation detection in the fast DC SA, for branches that have been disabled on one side due to a contingency.
What is the current behavior?
Currently, if branches are disabled only on one side (for example, in the case of a contingency on a busbar section), the fast DC SA will compute network results and may detect limit violations on these branches.
This behavior differs from the slow DC SA, as the latter uses a listener to replace
ClosedBranchSide1/2DcFlowEquationTerm
withEvaluableConstants.ZERO
when one side of the line is disabled. As a result, branch results are set to 0 on both sides, and no limits are violated (although they are still analyzed).What is the new behavior (if this is a feature change)?
In fast DC SA, a customized filter is now applied before computing the network results or checking for limit violations. This filter is inspired by the work done in PR #1169.
A branch where one side is disabled by a contingency is considered disabled, meaning no computation or verification is performed on these branches. This differs from the slow DC SA (see the previous paragraph), where the filter simply checks whether the branches have been disabled on both sides by the contingency.
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: