Refactor Woodburry matrix identity usage

[Hadrien-Godard]

Describe the current behavior

Currently, the Woodburry matrix identity usage is coded in the DCsensitivityanalysis rather than be a generic tool callable by any class. For instance, this implies that the DCsecurityAnalysis is currently calling the DCsensitivityanalysis to benefit from it.

Describe the expected behavior

The expected behavior is to have a dedicated class to compute DCflows/sensitivities using the Woodburry matrix identity.
This class is expected to be called both by the DCsecurityAnalysis and DCsensitivityanalysis.
It is also expected to handle more generic admittance shifts than just branch disconnections. For instance, branch reconnections or transformer tap changings.

The class could be instantiated with:

• A LU matrix decomposition.
• An admittance shift. It could be described as a list of branch disconnections, reconnections and transformer tap changings.
• A network "state". It represents the right hand side in the linear system, i.e. the bus active power balances in case of a security analysis, or the variable function in case of a sensitivity analysis.
• A list of flows to compute.

Then, the class is expected to have a method to compute the flows corresponding to the state using the given LU matrix decomposition, rather than recompute the admittance matrix and its LU decomposition.

Describe the motivation

The motivation is to have a dedicated method to use the Woodburry matrix identity that could be callable than to have it implicitly embedded in the sensitivityAnalysis. It also allows to generalize the usage of this identity to handle branch reconnections and transformer tap changings.

Extra Information

More information on a way to implement the solution of this issue.

Steps:

1. Create a WoodburryEngine class in dc folder. This class is centered on a “compute” method. This method takes as inputs:

   • A LU matrix decomposition (coming from the dc lf engine).
   • A list of admittance shifts. It could be described as a list of branch disconnections, reconnections and transformer tap changings. In the biggening, only branch disconnections.
   • A list of elements to be computed with the Woodburry matrix identity. Each element is composed of:
     • A network "state". It represents the right-hand side in the linear system, i.e. the bus active power balances in case of a security analysis, or the variable function in case of a sensitivity analysis.
     • A list of flows to compute, identified by the branches.

2. Fill the WoodburryEngine class thanks to methods in DcSensitivityAnalysis class. Check

3. Use the WoodburryEngine class in DcSensitivityAnalysis. Check

4. Use the WoodburryEngine class in DcSecurityAnalysis. Check

5. Extend the WoodburryEngine to deal with other admittance shifts.

The connectivity loss part could be done using the WoodburryEngine.
I think that the majority of the methods in DcSensitivityAnalysis related to N-1 sensitivity computations has to be changed, not just moved to WoodburryEngine.

[annetill]

Update: we support since version 1.9.0 a DC load flow and a DC security analysis with an HVDC in AC emulation (in the network and as a contingency). This is not supported at all in DC sensitivity analysis. If we want to have a slow mode and a Woodburry mode for DC security analysis, we have to support in Woodburry engine all the already supported contingency of the slow mode. For HVDC in AC emulation as contingency, some deep work inside Woodburry is needed. This will raised:

• Can we imagine LfHvdc being an implementation of LfBranch? This will have consequences: the hvdc line will be a branch in the connectivity for example.
• If not, we must rework on the Woodburry engine to work for both branches and hvdcs.
• Note that we also have a remedial action that change the operating mode of the hvdc from AC emulation to set point.