Hi Victor, The algorithm implemented in MIPS, including the various default parameters and convergence/failure criterion, were taken directly from an implementation in C by H. Wang (available as TSPOPF). The purpose of alphap and alphad are described at the end of Section A4.4 in the User’s Manual (taken directly from Wang’s thesis and paper). So when these Newton step scale factors get small enough, it essentially means that progress has stalled.
Unfortunately, I do not know the rationale or testing that went into the selection of the alpha_min value that is being used, since I simply took it from Wang’s code. I certainly think that this value could be turned into a user-settable parameter. I’m also happy to change the default value if it makes sense. Unfortunately, tuning these things requires lots of runs on many different kinds of problems to be sure that you have a default that is reasonable for most situations. It wouldn’t be good, for instance, if changing this resulted in an order of magnitude increase in the amount of time required to give up on an infeasible problem. It also seems to me that changing the criteria to require both scale factors to be smaller than the tolerance (alphap < alpha_min && alphad < alpha_min) before giving up might be a more logical way to detect a stalled solution. Opinions? -- Ray Zimmerman Senior Research Associate B30 Warren Hall, Cornell University, Ithaca, NY 14853 phone: (607) 255-9645 On Oct 28, 2013, at 1:26 PM, Victor Hugo Hinojosa M. <[email protected]> wrote: > Dear Professor Zimmerman, > I’d like to know about the numerically failed criterion used by MIPS > algorithm. I attach the code used in the mips.m file. > > alpha_min = 1e-8; %% OPT_AP_AD_MIN > > if any(isnan(x)) || alphap < alpha_min || alphad < alpha_min || ... > gamma < eps || gamma > 1/eps > if opt.verbose > fprintf('\nNumerically Failed\n'); > end > eflag = -1; > break; > end > > > The MIPS algorithm implemented in Matpower is considered to have failed when > the primal and dual variables (alphap and alphad) are lower than a critical > value. > For example, in the Garver test system I obtained the attached configuration > (garver_no_CV.m), where MIPS algorithm numerically failed; Virtual generators > are modeled in bus 2, 4 and 5. You could simulate the configuration using the > code “mpopt=mpoption; mpopt=mpoption('OPF_ALG',200,'VERBOSE',3); > rundcopf(garver_no_CV,mpopt);”. > You can see that the algorithm fails in 23 iterations, but if you analyze the > decision variables in the last iteration, you will note that the solution > point is very near the optimal solution. The algorithm fails because the > condition used by MIPS (alphap < alpha_min || alphad < alpha_min), so I > realize that the algorithm needs more iterations to solve the DC-OPF problem. > Considering a sensitivity analysis, I use another alphan_min values (1e-9 and > 1e-10), and I run the DC-OPF problem again. The problem converges to the > optimal solution. > I’d like to know about failed criterion used by MIPS algorithm in order to > understand the criterion and give some opinions about it. I have the > following questions: 1) Is the condition necessary?; and 2) What was the > criterion to formulate this condition? > I accomplished a sensitivity analysis, and my recommendation will be increase > the critical value to 1e-10. I solved the static transmission planning > problem with this value using the SRA evolutionary algorithm, and I cannot > find any infeasible solution (numerically filed) conducting 100 simulations. > I think the DC-OPF problem modeled by linear objective function and linear > constraints must find the optimal solution using the MIPS algorithm. > I’ll wait for your comments and opinions about the analysis accomplished. > Regards, > Vh > > De: [email protected] > [mailto:[email protected]] En nombre de Victor Hugo > Hinojosa M. > Enviado el: lunes, 23 de septiembre de 2013 11:09 > Para: 'MATPOWER discussion forum' > Asunto: RE: Reasons for non convergence of optimal power flows > > Dear Professor Zimmerman, > I’d like to study in more detail the problem of the initial point, so I want > to keep on working in this issue in order to obtain a better criterion. In > this moment, my single recommendation will be that user should consider a > different point. > I think that the PTDF factors can help to improve the convergence of the MIPS > algorithm, so I need more time to develop some criterions. > Regards, > Víctor > > De: [email protected] > [mailto:[email protected]] En nombre de Ray Zimmerman > Enviado el: lunes, 16 de septiembre de 2013 13:35 > Para: MATPOWER discussion forum > Asunto: Re: Reasons for non convergence of optimal power flows > Importancia: Alta > > Thanks Victor for your input. The initial point used by MATPOWER for the MIPS > solver was simply an attempt to begin at some interior point, so I'm not > surprised at all to hear that selecting a different starting point can > sometimes result in convergence of case that ran into numerical problems. > > What wasn't clear to me was whether your tests suggest a way of selecting a > starting point that is likely to be consistently better than the one > currently being used. Or is it just an issue of – when one doesn't work, try > a different one? > > -- > Ray Zimmerman > Senior Research Associate > B30 Warren Hall, Cornell University, Ithaca, NY 14853 > phone: (607) 255-9645 > > > > > > > On Sep 13, 2013, at 4:21 PM, Victor Hugo Hinojosa M. <[email protected]> > wrote: > > > Dear Professor Zimmerman and Santiago, > I had the same problem that Santiago mentioned when I applied an evolutionary > algorithm to the static and dynamic transmission expansion planning problem > (TEP). The algorithm was based on local random search, so many configurations > from the solution space were analyzed. I realized that some configuration > didn’t converge the Matpower, and I was trying to find out about this problem. > For example, in the Garver test system I applied the evolutionary algorithm > to the static problem, and I obtained the attached configuration where MIPS > algorithm numerically failed. In the same way, I considered virtual > generators (bus 2, 4 and 5). > The MIPS algorithm don’t solve the DC-OPF problem for this configuration > “mpopt=mpoption; mpopt=mpoption('OPF_ALG',200,'VERBOSE',3); > rundcopf(garver_no_CV,mpopt);”. > This problem occurs due to the initial point that the MIPS algorithm use. In > the MIPS solver, the initial point is obtained considering the average power > between the minimal and maximal power for each generator. When I changed the > initial point to the minimal power generation (x0=[0 0 0 0 0 0]), the MIPS > algorithm converges. > I had conducted some proofs in order to determine some initial points where > the algorithm has convergence problems. I’ve divided each generator range, so > the MIPS algorithm can consider different initial points. I included three > analysis. > In first case, I divided the power range in 8 intervals for each generator, > so I can combine the power for each generator as initial point. The total > points that the algorithm must consider is 531 441 (9^6). For these points, > the MIPS algorithm doesn’t converge in 15 078 times (2.84%). In the second, I > divided in 9 intervals, so the total points is 10^6. In this case, the MIPS > algorithm doesn’t converge in 14 492 times (1.45%). Finally, I divided in 10 > intervals, so the total points is 11^6. In this case, the MIPS algorithm > doesn’t converge in 42 016 times (2.37%). I attached an excel file where it’s > possible to figure out the initial points that the MIPS algorithm doesn’t > converge considering 4 intervals. In the row 339, it’s possible to see the > initial point used by Matpower. > I had the same problem when I used the MIPS algorithm considering the power > generator as decision variable. The solution could be to consider another > initial point, but I’d like to study again the problem. > I hope your comments and ideas about the analysis carried out. > Regards, > Víctor > > > De: [email protected] > [mailto:[email protected]] En nombre de Ray Zimmerman > Enviado el: martes, 28 de mayo de 2013 11:34 > Para: MATPOWER discussion forum > Asunto: Re: Reasons for non convergence of optimal power flows > > Islands should not be a problem as long as there is a REF bus in the island > and the available generation is sufficient to meet the load in each island. > So (1) is a definite possibility, but (2) shouldn't be an issue. Insufficient > reactive power range to keep voltage magnitudes within range, and overly > restrictive branch flow limits could be other causes of an infeasible OPF > problem. Aside from things that can cause the problem to actually be > infeasible, there are also numerical issues that can affect feasible > problems. These can be the result of large ranges in parameters (branch > impedances, generator costs, etc.). In these cases, often a different solver > or algorithm may be able to solve the problem successfully. > > Hope this helps, > > -- > Ray Zimmerman > Senior Research Associate > 419A Warren Hall, Cornell University, Ithaca, NY 14853 > phone: (607) 255-9645 > > > > > > > > On May 20, 2013, at 1:21 PM, Santiago Torres <[email protected]> wrote: > > > > > Dear Ray, I my resarch work I am using many transmission topologies and also > I am using ficticious generators in order to get optimal power convergence > for those different transmission topologies. Using those artificial or > ficticious generators in all exclusive load buses is suposed to help for > convergence, however in practice I am getting some transmission > configurations that do not achieve convergence. > > I am thinking in the following reasons: > > 1) Too strict power generation limits of ficticious generators. > > 2) Some topologies with islanded nodes. > > Can you think in other reasons? > > Islanded nodes is a non convergence cause in Matpower? > > Best Regards, > > Santiago > > -- > Dr.-Ing. Santiago Torres > IEEE Senior Member > > Post-Doctoral Fellow > School of Electrical and Computer Engineering > > > University of Campinas, Campinas, SP, Brazil > > http://www.dsee.fee.unicamp.br/ > > Albert Einstein, 400 > 13083-852, Campinas, SP, Brazil > > <garver_no_CV.m><No_CV_analysis.xlsx> > > <garver_no_CV.M>
