-
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
Improve performance of incremental outer loops #895
Conversation
Signed-off-by: Caio Luke <caioluke97@gmail.com>
Signed-off-by: Caio Luke <caioluke97@gmail.com>
...main/java/com/powsybl/openloadflow/ac/outerloop/IncrementalShuntVoltageControlOuterLoop.java
Outdated
Show resolved
Hide resolved
...ava/com/powsybl/openloadflow/ac/outerloop/IncrementalTransformerVoltageControlOuterLoop.java
Outdated
Show resolved
Hide resolved
Signed-off-by: Caio Luke <caioluke97@gmail.com>
@caioluke is this optimization based on some performance profiles? Do you have observed in a real case a significant performance improvement? |
@geofjamg yes we observed the issue on large networks. Flamegraph before (outerloop is taking more time than the NR ...): solution "path" unchanged but much faster (left is before fix, right after fix): |
Indeed. |
I summarize the discussion I had with @caioluke:
@jeandemanged @Hadrien-Godard what do you think? |
# Conflicts: # src/main/java/com/powsybl/openloadflow/ac/outerloop/IncrementalShuntVoltageControlOuterLoop.java # src/main/java/com/powsybl/openloadflow/ac/outerloop/IncrementalTransformerVoltageControlOuterLoop.java
Signed-off-by: Caio Luke <caioluke97@gmail.com>
Signed-off-by: Caio Luke <caioluke97@gmail.com>
Signed-off-by: Caio Luke <caioluke97@gmail.com>
double diffV = controlledBus.getHighestPriorityMainVoltageControl().orElseThrow().getTargetValue() - voltageControl.getControlledBus().getV(); | ||
double halfTargetDeadband = getHalfTargetDeadband(voltageControl); | ||
if (Math.abs(diffV) > halfTargetDeadband) { | ||
List<LfShunt> controllers = voltageControl.getMergedControllerElements().stream() |
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.
We have a difference here in the way we get controllers from a controlled. In previous code, we use IncrementalContextData.getControllerElements
which has a filter on voltage control type. Is it equivalent?
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.
Yes, it is equivalent. I directly call the method for the specific type of voltage control: getShuntVoltageControl
or getTransformerVoltageControl
. And I also filter out the disabled controllers.
...ava/com/powsybl/openloadflow/ac/outerloop/IncrementalTransformerVoltageControlOuterLoop.java
Show resolved
Hide resolved
…ts for transformer outerloop Signed-off-by: Caio Luke <caioluke97@gmail.com>
This reverts commit 121c9f8.
@@ -191,11 +201,26 @@ private boolean adjustWithSeveralControllers(List<LfBranch> controllerBranches, | |||
} | |||
|
|||
private static double getDiffV(TransformerVoltageControl voltageControl) { | |||
double targetV = voltageControl.getTargetValue(); | |||
double targetV = voltageControl.getControlledBus().getHighestPriorityMainVoltageControl().orElseThrow().getTargetValue(); |
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.
@jeandemanged and @geofjamg bug fix here. We have to check the voltage difference against the voltage control of highest priority, most of the time those of the generator and not those of the transformer.
Maybe a final performance test is needed before merging and a unit test that shows the bug. |
Signed-off-by: Caio Luke <caioluke97@gmail.com>
.setRegulating(true) | ||
.setTapPosition(0) | ||
.setRegulationTerminal(line34.getTerminal2()) | ||
.setTargetV(33.0); |
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.
Change this targetV to 30.0 to show the benefit of the bug fix.
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
Kudos, SonarCloud Quality Gate passed! |
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.
all good, thanks
other improvements (see here) would be in other PRs
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
What kind of change does this PR introduce?
Performance enhancement
What is the current behavior?
We currently calculate sensitivity for all controllers of the network, even though we won't need them all.
What is the new behavior (if this is a feature change)?
Sensitivities are only calculated for the necessary controllers (outside target/deadband).
Does this PR introduce a breaking change or deprecate an API?
No
Other information: