Very interesting. I am quite surprised at the consistency independent of location. And yes, it really is just two generators whose outputs are linked. For the cases that solve, is the DC line being dispatched at zero? At max capacity? Somewhere in between? Does changing the loss parameter make any difference? What sort of nodal price spread do you have before introducing the DC line? If the price spread is non-trivial and the DC line is lossless, I can’t see why it should be numerically more difficult than the original problem.
I just ran a quick test using one of the Polish models and it didn’t make any difference in the number of iterations, either for MIPS or IPOPT, which is what I would expect. At this point, I can think of two possibilities … 1. Something is rather unique about your system and I don’t know what it is. 2. Something got messed up with your MATPOWER installation and it’s not running the code we think it is. (You are running an unmodified MATPOWER installation, right? If so, maybe try installing a fresh version and make sure there’s nothing extraneous in your Matlab path that would override any of MATPOWER’s files with other versions). If you like, feel free to send me (off list) the case and a script that duplicates the problem and I’ll see if I can replicate the issue. Very strange indeed, Ray > On Apr 14, 2015, at 6:17 AM, Eser Patrick <[email protected]> wrote: > > 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 >
