[Draft] Improve fast DC AS performances #1169
Conversation
Signed-off-by: Geoffroy Jamgotchian <geoffroy.jamgotchian@rte-france.com>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
…improve_dc_woodbury_perfs
| @@ -83,6 +81,7 @@ public static double[] runDcLoadFlowWithModifiedTargetVector(DcLoadFlowContext l | |||
|
|
|||
| DcLoadFlowParameters parameters = loadFlowContext.getParameters(); | |||
| if (parameters.isDistributedSlack()) { | |||
| // FIXME, distribution keys has changed... | |||
There was a problem hiding this comment.
@p-arvy here is why we stop, as slack distribution keys have changed, the trajet vector has to be updated. Doing it by hand is really complex and in a way a code duplication, so it could be nice if you test a DC network save/restore with the less possible number of fields (only buses, some branches, all branches, which attributes inside).
There was a problem hiding this comment.
Okay thank you for the feedback @annetill. I will take a look.
There was a problem hiding this comment.
Hello @annetill, @geofjamg, my understanding is that we want to return to applying the LfContingency, but this time saving/modifying/restoring the least possible number of fields.
In doing so, I have the impression that it is sufficient to apply the generators/loads/hvdcs changes due to the LfContingency, and save/restore the BusDcState of the LfNetwork, as the impact of changes on other elements (lost buses/PSTs) is already accounted for in the RHS override by directly modifying the target vector array (in method WoodburyEngine.runDcLoadFlowWithModifiedTargetVector). What do you think ?
I have pushed a commit in this regard (note that the code is not yet clean). Please feel free to comment.
There was a problem hiding this comment.
I also rolled back to have the case distinction when the contingency causes generator/load losses or not (to avoid having to save/apply/restore the modifications). This reduces significantly execution time in case of branch contingencies.
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
# Conflicts: # src/main/java/com/powsybl/openloadflow/sa/WoodburyDcSecurityAnalysis.java
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
# Conflicts: # src/main/java/com/powsybl/openloadflow/sa/WoodburyDcSecurityAnalysis.java
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
Signed-off-by: p-arvy <pierre.arvy@artelys.com>
|
@vidaldid-rte only the state vectorization remains to be integrated (see class Another improvement that had been explored in the PR was determining the most restrictive limits on the branches, in order to more quickly check for violations (~10% time improvement). However, the code is incomplete / not well tested. The PR can either be kept open to continue exploring this development, or closed and replaced with an issue listing both improvements for future follow-up. |
Please check if the PR fulfills these requirements
No, because this PR should never be merged but separated in small PRs.
Does this PR already have an issue describing the problem?
No, but the fast DC AS is not as fast as expected. For 3000 branch contingencies in the 400-225 kV french network, it is only 50% faster than the classical DC AS.
What kind of change does this PR introduce?
Many trials, to be discussed with @geofjamg and @p-arvy. We stopped the PR because our first goal was to delete totally network saving and restoration. Because of slack distribution, it could lead to a complex duplication of some existing code (see the update of DC target vector). So we think now that a first quick win could be to create a DC network save/restore with as less as possible fields.
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: