Ray, Thanks for you inputs. Please allow me to follow up on this.
First of all, I investigated the dependency of described phenomenon on the location of the DC line. Contradicting your prediction, the problem was not function of the location. See the table/list below for these findings. (All using ACOPF with IPOPT) Location of DC line / toggle_dcline (on/off) / Runtime until converged (iterations) ———————————————————————————————————————— 1 / off / 5 sec (42 iterations) 1 / on / 42 sec (315 iterations) 2 / off / 5 sec (42 iterations) 2 / on / 34 sec ( 309 iterations) 3 / off / 5 sec (42 iterations) 3 / on / 36 sec (310 iterations) 4 / off / 5 sec (42 iterations) 4 / on / 35 sec (318 iterations) Conclusion: I placed the DC line (10 MW capacity in 100+ GW system) in four random locations. The resulting increase in runtime and iterations was always found. Since I couldn’t get MIPS to run with this original case, I went back to an older, smaller case (ca. 200 buses, 15 GW system). Here, I check for several locations again, but now I also switched between IPOPT and MIPS. Location of DC line / Solver used / toggle_dcline (on/off) / Runtime until converged (iterations) ———————————————————————————————————————— 1 / IPOPT / off / 0.7 sec (36 iterations) 1 / IPOPT / on / 1.6 sec (94 iterations) —> Same phenomenon again: Adding one DC line heavily increases the number of iterations 2 / IPOPT / off / 0.7 sec (36 iterations) 2 / IPOPT / on / 1.8 sec (100 iterations) —> As seen in table above: The runtime increase is not location-specific 1 / MIPS / off / 0.8 sec 1 / MIPS / on / no convergence —> Reason: Numerically failed, matrix was close to singular 2 / MIPS / off / 0.7 sec 2 / MIPS / on / no convergence Conclusion: I can observe again, that addition of one small DC line heavily increases the necessary number of iterations. And again, this phenomenon holds true for all tested locations (I’ve tested more than reported here). The MIPS result indicate why: Addition of the DC line seems to push the system close to a singular matrix. This is exactly what you had predicted, Ray. But at the same time I’m wondering: Why is this happening? I mean effectively, the toggle_dcline adds two generators and the two ends of the DC line, and links their power output to each other, correct? Is this changing the problem so much on the numerical level? Is there another way of doing it? Maybe keep the line an AC line, but scale R, X and B to make it a “quasi-DC” line? I’d be happy if other users could also report their experience with the DC line implementation in MATPOWER. Because for my case described above, this issue even means the step from perfectly converging to non-converging cases (when using MIPS). Even when the added line itself is completely insignificant within the overall system. Best, Patrick From: Ray Zimmerman <[email protected]<mailto:[email protected]>> Reply-To: MATPOWER discussion forum <[email protected]<mailto:[email protected]>> Date: Monday 13 April 2015 16:30 To: MATPOWER discussion forum <[email protected]<mailto:[email protected]>> Subject: Re: Simulation slow down due to addition of DC lines I suppose this is a bit unusual, but I don’t think you are doing anything wrong. The most likely explanation is simply that adding a dispatchable DC line where you did somehow makes the problem numerically much more difficult to solve. You might try changing the from and to bus parameters for the line (i.e. moving it around the network). My guess is that you’ll find some cases solve just as quick as the original and some (like your original location) take much longer. I’d be curious to know whether you see the same sort of variation in solve times when using a different solver (such as MIPS, fmincon or Knitro). -- Ray Zimmerman Senior Research Associate B30 Warren Hall, Cornell University, Ithaca, NY 14853 USA phone: (607) 255-9645 On Apr 13, 2015, at 7:51 AM, Eser Patrick <[email protected]<mailto:[email protected]>> wrote: Dear MATPOWER community, I have a question regarding adding DC lines to an AC system with the “toggle_dcline" command. I am running a 1100-bus system, using IPOPT as solver. When I solve the standard ACOPF system, the simulation converges within 7 seconds (40 iterations). Now when I add one DC line of 10 MW capacity, applying the “toggle_dcline” command, the system needs 38 seconds (310 iterations) to converge. Since I have not really changed the system with adding one single 10 MW DC line, the results between both cases are 99.99% identical. So why is it, that the DC-line case needs so much more iterations to converge (factor 5 more)? The parameters of my fictitious DC line are: PMAX = +10 MW PMIN = -10 MW QMINF, QMINT both = -10 MVAr QMAXF, QMAXT both = +10 MVAr VF, VT both = 1.0 p.u. LOSS0 = 0.1 LOSS1 = 0 (since I want to enable the code to use the DC in both directions, following a comment in the MATPOWER manual) Have I messed up the definition of the DC line? If not, is there a workaround to bring individual DC lines into a predominantly AC system without having a runtime penalty of factor of 3-5? Or do I just need to re-adjust several parameters of the IPOPT solver to set it up for new constraints of the type “lower bound only”? In the AC-only system, I only have “both lower and upper bound” constraints, so maybe my IPOPT is set up to handle only those constraints properly? Any hints would appreciated. Thanks a lot. Best, Patrick Eser
