-
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
Refactor DC Outer Loops creation #1158
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Signed-off-by: vmouradian <[email protected]>
Quality Gate passedIssues Measures |
Support of OuterLoopNames parameters for DC is in this separated PR : #1159. |
// remove area interchange control outer loop if no area in the network, active power will be distributed with classical slack distribution | ||
boolean areaInterchangeControl = outerLoops.stream().anyMatch(DcAreaInterchangeControlOuterLoop.class::isInstance); | ||
if (!network.hasArea()) { | ||
outerLoops.removeIf(DcAreaInterchangeControlOuterLoop.class::isInstance); |
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.
don't remove the outerloop here.
the outerloop should handle the 'no area' situation by itself.
implements OuterLoop<V, E, P, C, O>, ActivePowerDistributionOuterLoop<V, E, P, C, O> { | ||
implements ActivePowerDistributionOuterLoop<V, E, P, C, O> { |
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.
since AbstractActivePowerDistributionOuterLoop implements ActivePowerDistributionOuterLoop, this part is redundant and can be removed too
implements ActivePowerDistributionOuterLoop<V, E, P, C, O>
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Part of #1091 + adds consistency (imo)
What kind of change does this PR introduce?
Feature / refactor
What is the new behavior (if this is a feature change)?
DC Outerloops creation is made more consistent with AC ones (created in the OLF parameters class then are contained in DcLoadFlowParameters)
Support of
outerLoopNames
parameter for DC is in this separated PR : #1159.Does this PR introduce a breaking change or deprecate an API?