[docs] Complex number AC Optimal Power Flow tutorial

[odow]

Rebase of #3382

@jd-foster you should be able to pull and push from this branch now.

Preview: https://jump.dev/JuMP.jl/previews/PR3395/tutorials/applications/optimal_power_flow/

Closes #3363

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (4a304dd) 98.06% compared to head (cb5c368) 98.07%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3395   +/-   ##
=======================================
  Coverage   98.06%   98.07%           
=======================================
  Files          34       34           
  Lines        4922     4927    +5     
=======================================
+ Hits         4827     4832    +5     
  Misses         95       95           

see 2 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[odow]

This should definitely be moved to the /applications directory. I can see it being useful for EE people, but it might be too detailed for a general conic example to expect people to read.

[jd-foster]

Ok, moved to the /applications directory and removing the WIP label.

[jd-foster]

@frederikgeth @ccoffrin I would appreciate any comments or improvement suggestions if you get a chance.

Preview: https://jump.dev/JuMP.jl/previews/PR3395/tutorials/applications/optimal_power_flow/

[ccoffrin]

I didn't have a chance to look at the original version of this but I am a little surprised to see that line flow limits are not included (or did I miss them?). I also generally find the matrix-centric version of formulation difficult to follow. I prefer explicitly writing the line flow equation like conj(Y+Y_fr)/(T*conj(T))*V_fr*conj(V_fr) - conj(Y)/T*V_fr*conj(V_to) but the matrix form is worth it to make the SDP constraint easer to setup.

I saw a place or two where the use of abs2 might further simplify the presentation.

FWIW, here is the formulation I came up with based on my preferred formulation style, https://github.com/lanl-ansi/rosetta-opf/blob/main/variants/jump-rectangular-complex.jl

Looking at the JuMP docs, I think my example could be improved further by defining the variables in the complex plain directly.

[jd-foster]

@ccoffrin Thanks Carleton, that's useful feedback.

original version of this

This has been written from scratch; was there another tutorial I missed? Sorry if I'm not understanding you.

[frederikgeth]

Thanks for this great contribution to the community. I have a few comments, to help reach the maximum audience.

• I prefer the terminology reference (angle) bus for what you're refering to as slack bus. You need the define one bus with a fixed voltage angle somewhere in the system, otherwise you have a degenerate problem. The concept of slack bus originates from having to balance out active and reactive power in power flow (not OPF). By setting imag(V[1]) == 0 you define the voltage angle at one bus to be 0 degrees, although in principle it could be any angle (offset) value. Note that you should in principle also restrict the sign of the real part real(V[1]) >= 0, as you otherwise also allow for a second solution with a 180 degree angle, and from experience in unbalanced OPF I know this can cause unexpected numerical issues.
• You could mention in the beginning what the general plan of action is before getting into the details, i.e. develop 1) a rectangular formulation in power-voltage variables 2) based on the nodal admittance matrix of the system. In my experience, the approach where you don't build a nodal admittance matrix build construct the system of equations in a scalar fashion (like in PowerModels) is easier from the educational perspective, so it could be worth mentioning that these are two distinct approaches.
• For the sparse SDP form, you could refer the readers to
  @Article{6064917,
  author={R. A. Jabr},
  title={Exploiting Sparsity in SDP Relaxations of the OPF Problem},
  journal={IEEE Transactions on Power Systems},
  volume={27},
  number={2},
  pages={1138-1139},
  year={2012},
  month={May},
  doi={10.1109/TPWRS.2011.2170772},
  ISSN={0885-8950}
  }
• The W+V SDP relaxation section I find a bit unintuitive. You may want to mention why you're note defining W as PSD anymore at time of construction, and why this then requires you to set imag(W[i, i]) == 0 and real(W[i, i]) >= 0. Also, discuss why sum(P_G) >= sum(P_Demand) appears out of nowhere? You could also straight-away define @constraint(model, [i in 1:N], 0.9^2 <= real(W[i, i]) <= 1.1^2) where you define @constraint(model, [i = 1:N], real(W[i, i]) >= 0)? I'm not even sure why the gap would be worse? Similarly, the convergence shouldn't depend on start values so that's strange to see them? The significant difference in values or the voltage magnitude also goes unexplained. Similarly, you do the posprocessing of the voltage magnitude still based on the W variables instead of the V variables, which sort of disagrees with your statement of 'has the advantage that we can work directly with complex voltages to extend the formulation'. I may be misunderstanding something here.
• You could mention that if the solution has a rank-1 W matrix, that the result would be exact, and that you could then uniquely post-process the angles?

edit: Just saw Carleton's reaction, my point 2 is the one that Carleton made already

[jd-foster]

@frederikgeth Thanks Fred. I will definitely incorporate your first three points directly.
Your fourth point is insightful: I was already thinking of just deleting that last W+V section entirely for all those reasons as it wasn't adding much as a result. Unless I can use it to add something distinctive, I still might.

[frederikgeth]

I agree, at the moment the SDP W+V section doesn't really add much to the story or goals of this tutorial. It may be worth fleshing out at a later stage.

If you prefer to keep SDP W+V, I would consider putting it before SDP W. It is easier to explain the lifting and reformulation if you keep both V+W initially. And then you can tell the story of how you can get rid of the V variables and still recover the same solution (for the SDP W section).

[jd-foster]

Good, that story makes a lot more sense to me.
The alternative I was considering was to make use of the voltage variables with observation that the voltage angles are "small" (between -5 and 15 degrees) in the global nonlinear solution, and use that information to bound them away from the origin (above the chord that joins rays at those angles and the lower voltage magnitude "circle"), recovering the voltage constraints that bind at the global optimum. Of course that's a whole other layer of complexity.

[odow]

LGTM. I don't really have an opinion on the SDP formulations. We can always merge and wait to see if we get any feedback from students etc.

[jd-foster]

Great, I'm excited to get this merged!

[jd-foster]

(I couldn't help doing it myself this time 😂)

[odow]

I couldn't help doing it myself this time

Haha. I was going to wait to see if anyone had other comments. But no harm no foul.

[jd-foster]

Thanks!
If anyone has any comments, please do post them.

[ccoffrin]

I'm hoping to do another pass.

[ccoffrin]

Old link to rendered preview version is broken, where can I view the latest version?

[jd-foster]

https://jump.dev/JuMP.jl/dev/tutorials/applications/optimal_power_flow/