Refactor separation of post contingency calculations in Woodbury DC Security Analysis #1125
Conversation
p-arvy
changed the title
p-arvy
changed the title
Thank you for the review. Done. |
There was a problem hiding this comment.
As discussed with the team I would find it easier to read if the BiConsumer postContingencyResultAdder was instead defined as a method (because here we start reading runSimulations with this thing out of the calling context.
But OK to merge since this solves the issue of duplicated code.
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Okay, thanks for the comment. I moved the BiConsumer |
|
vidaldid-rte
deleted the
refactor-connectivity-break-distinction-in-woodbury-dc-sa
branch
…ecurity Analysis (#1125) Signed-off-by: p-arvy <pierre.arvy@artelys.com> Signed-off-by: Didier Vidal <didier.vidal_externe@rte-france.com>
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?
The distinction between post contingency result computation is refactored in Woodbury DC Security Analysis.
What is the current behavior?
In current behavior, code is duplicated. The only difference between the two calculations is the method used to calculate post contingency states (conditionned by post contingency connectivity result).
What is the new behavior (if this is a feature change)?
The code is mutualized.
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: