Fast security analysis

[geofjamg]

We need to implement a security analysis much faster than default one provided by com.powsybl.security.SecurityAnalysisImpl which is an external loop over com.powsybl.loadflow.LoadFlow run.

• A security analysis implement com.powsybl.security.SecurityAnalysis
• In order to be fast here is some design consideration:
  • A single LfNetwork instance has to be built for all contingency simulation. This one should include all couplers necessary to simulate contingency list.
  • A pre-analysis has to be done on IIDM network (without any modification of it and without any variant creation).
  • ContingencyTopologyTraverser could be helpful to identify for each of the contingency the branches and couplers that could be opened to simulate the contingency (fault propagation analysis).
  • A connected component calculation has to be done also for each contingency to check if connected component is split or not byt the equipments removal. As this calculation is a large part of total calculation time we will try first a naive implementation of connected components (like https://jgrapht.org/javadoc-1.4.0/org/jgrapht/alg/connectivity/ConnectivityInspector.html) then an optimized one (like https://dl.acm.org/doi/10.1145/322234.322235).
  • From previous analysis we are able to build a LfNetwork with all necessary bus/branch/coupler and also for each of the contingency a list of bus/branch/coupler to remove in order to simulate the contingency taking into account the fault propagation.
  • Core of security analysis is implemented with an OuterLoop instance.
  • This outerloop is executed one time for base analysis and then one time for each contingency of the list.
  • Base iteration is done using full equation system.
  • For each contingency iteration of this outer loop:
    • At beginning of the loop, equation system is updated to remove all equations related to bus/branch/coupler that should be removed for the current contingency.
    • At end of the loop security limits are verified and stored in the OuterLoop instance.
    • Equation system is restored in its original state (full).
  • Each contingency analysis start from base calculation state using a NR warm start.

Some other performance ideas:

• https://github.com/powsybl/powsybl-open-loadflow/pull/77 is a prerequisite.
• Equations evaluation has to be optimized to lazy evaluate (because actually lots of equation are not active and don't need to be evaluated at each NR iteration).
• Equations could be evaluated using GPU (vectorial calculation).
• In order to avoid recreation of Jacobian structure after any equation add/removal/activation we could imagine a system of mutually exclusive equation pair than could share the same matrix row (Q and V for a generator bus for instance). So we could be able to only have one Jacobian structure for all NR iterations.

[annetill]

This issue is partially solved by this https://github.com/powsybl/powsybl-open-loadflow/pull/135

The beta version of the security analysis that is merged on master branch does not support:

• Network in bus/breaker topology ;
• Equipements as contingency that are not branches ;
• Current temporary limits ;
• Apparent power limits: permanent and temporary ;
• To remove from slack distribution the loads and the generators that are disconnected through the contingency ;
• Contingency that separates controllers buses/branches and controlled bus/branch ;
• Contingency that separates shared controllers ;
• The current computation in the equation system (and not as a post processing).

[annetill]

The DC mode of the fast security analysis would be more efficiently done through our new OpenSensitivityAnalysisProvider. This mode could support actions too.

[annetill]

We still have a beta version of the security analysis. What we still need to support is:

• Equipements as contingency that are not branches: loads, generators, static var compensators, VSC, shunt compensators, bus bar sections, HVDC lines. The HVDC contingency is not done correctly as we don't model the physical link between the two converter stations. I have started a small prototype for that based on variable equation terms.
• Apparent power limits: permanent and temporary ;
• To remove from slack distribution the loads and the generators that are disconnected through the contingency ;
• Contingency that separates controllers buses/branches and controlled bus/branch ;
• Contingency that separates shared controllers (see CGMES conformity test cases) ;

[annetill]

@obrix and @Hadrien-Godard can you handle the two first bullets points?

• For all ContingencyElementType support, I think that you can start with GENERATOR and SVC.
• For all kind of limits: the apparent power limits and active power limits. You can start with ActivePowerLimits (in MW) and continue with ApparentPowerLimits (in MVA).

[geofjamg]

I close this issue because most of it has been done and because it is too generic. Additional issues will be created to improve security analysis.