Yes, thanks, Jose. I’ve added another item to FAQ #5 with links to your posts.
Ray > On Aug 16, 2015, at 11:03 PM, Abhyankar, Shrirang G. <abhy...@anl.gov> wrote: > > Thank you. > > On Aug 15, 2015, at 12:06 PM, "Jose Luis Marin" <mari...@gridquant.com > <mailto:mari...@gridquant.com>> wrote: > >> Sure, of course I have no problem with that. >> >> Also, I realized I missed one detail: if there were any phase-shifters in >> the network, I would also (initially) set their phase-shifts to zero. That >> way you would obtain a truly "pure reactive" network. Then, when you work >> your way ramping up real power, you would also want to ramp those >> phase-shifts back to their original values as well. >> >> -- >> Jose L. Marin >> Gridquant España SL >> Grupo AIA >> >> >> On Fri, Aug 14, 2015 at 10:17 PM, Abhyankar, Shrirang G. <abhy...@anl.gov >> <mailto:abhy...@anl.gov>> wrote: >> Jose, >> Would it be fine with you if the steps you’ve mentioned below are added to >> MATPOWER FAQ#5 http://www.pserc.cornell.edu//matpower/#pfconvergence >> <http://www.pserc.cornell.edu//matpower/#pfconvergence> Many a times, >> useful and detailed suggestions, such as what you’ve enumerated, get lost in >> email exchanges and someone trying to pull up this information has to resort >> to digging it out of the archive. It’ll be good to have your steps up on the >> FAQ. >> >> Thanks, >> Shri >> >> From: Jose Luis Marin <mari...@gridquant.com <mailto:mari...@gridquant.com>> >> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu >> <mailto:matpowe...@list.cornell.edu>> >> Date: Wednesday, August 12, 2015 at 2:42 AM >> To: MATPOWER discussion forum <matpowe...@list.cornell.edu >> <mailto:matpowe...@list.cornell.edu>> >> Subject: Re: convergence problem in runpf. >> >> Mirish, >> >> I couldn't help notice that you're building this model from scratch (well, >> from a database) and you mentioned "To make the problem simple I used all >> buses as PQ buses except one slack bus". This actually makes it harder to >> converge, unless you have *very* accurate data on what the reactive >> injections Q (on generator buses) should be. >> >> May I suggest a different, incremental approach: >> Start by keeping all generator buses you can as PV, instead of PQ. They will >> help holding up the voltage profile. After all, a PV node is a slack bus in >> what regards the reactive power injection. >> For the loads, start by zeroing out PD (real power demand), but keeping QD >> (reactive demand) >> For generators, set the scheduled PG to zero >> For lines & transformers, zero out the resistance R >> The resulting network will be a "purely reactive power" model. Now run a >> powerflow. If this doesn't have a feasible powerflow solution, it is >> because some branches have an X parameter that is too large (or >> equivalently, some load QD is too large). Ramp down the profile of QD until >> you see convergence. >> Look at the resulting Q flows across branches, and try to detect anomalously >> large values (i.e. clear outliers). They will help you uncover values of X >> that may be wrong (too large). Also, keep an eye on negative X coming from >> equivalents such as 3-winding transformers; they may also be wrong. >> Once you get that working, ramp up the values of PD on loads and PG on >> generators (keeping an eye on the swing's resulting PG, in order to >> redistribute big excesses). >> Finally ramp up the resistance on lines. >> The whole idea is based on the fact that, for transmission networks (lines >> with R<<X), the reactive flows are like the "backbone" on which real power >> flows can sort of "ride on". Get a healthy backbone first, and then you can >> start transporting real power. >> >> Hope it helps, >> >> -- >> Jose L. Marin >> Gridquant España SL >> Grupo AIA >> >> >> On Wed, Aug 12, 2015 at 2:36 AM, Mirish Thakur <mirishtha...@gmail.com >> <mailto:mirishtha...@gmail.com>> wrote: >> Dear Mr.Shree, >> >> Thank you very much for your help. As per your suggestion and FAQ I tried to >> find out the problems. >> The results I got- >> 1) Fast-decoupled power flow did not converge in 30 iterations. >> 2) By following http://www.pserc.cornell.edu/matpower/#pfconvergence >> <http://www.pserc.cornell.edu/matpower/#pfconvergence> I tried to runcpf to >> get good initial guess and i got results like >> step 1 : lambda = 0.084, corrector did not converge in 10 iterations. >> Where lambda is < 1 and for reducing steady state loading limitation I >> reduced demand less than 60 % which also failed to converge the power flow. >> 3) Also I tried to run an optimal power flow according to Dr. Ray's >> explanation given in following link- >> >> https://www.mail-archive.com/search?l=matpower-l@cornell.edu&q=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22&o=newest >> >> <https://www.mail-archive.com/search?l=matpower-l@cornell.edu&q=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22&o=newest> >> >> but got the results like- >> >> MATPOWER Version 5.1, 20-Mar-2015 -- AC Optimal Power Flow >> MATLAB Interior Point Solver -- MIPS, Version 1.2, 20-Mar-2015 >> (using built-in linear solver) >> it objective step size feascond gradcond compcond >> costcond >> ---- ------------ --------- ------------ ------------ ------------ >> ------------ >> 0 1200199.7 2.41677 0.71 536.762 >> 0 >> 1 946197.39 15.531 1.3682 1.75871 525.914 >> 0.209885 >> 2 954529.91 15.405 0.766107 0.203773 297.341 >> 0.00871422 >> 3 954849.8 12.849 0.727712 0.0545952 258.471 >> 0.00033166 >> 4 954629.03 13035 0.69114 0.107402 258.048 >> 0.000228815 >> 5 954614.88 33406 0.692682 0.255673 257.828 >> 1.46744e-05 >> 6 954525.69 14111 0.579613 0.143897 256.765 >> 9.24569e-05 >> 7 954539.42 61648 0.581139 0.501345 255.994 >> 1.42362e-05 >> 8 954518.93 22452 0.573652 0.478609 255.465 >> 2.12443e-05 >> 9 954494.92 8540.4 0.556318 0.403754 254.653 >> 2.48944e-05 >> 10 954523.58 20366 0.556265 0.570707 254.104 >> 2.97206e-05 >> 11 954522.07 6142.4 0.554989 0.647881 256.561 >> 1.57288e-06 >> 12 954573.42 6192.9 0.513972 0.716706 253.604 >> 5.32434e-05 >> 13 954575.97 5912.1 0.509457 0.699751 252.612 >> 2.64406e-06 >> 14 954576.23 16534 0.509454 0.674865 253.278 >> 2.64555e-07 >> 15 954579.65 12324 0.509394 0.812237 252.966 >> 3.54362e-06 >> 16 954579.86 7650.3 0.509391 0.80973 252.948 >> 2.18359e-07 >> 17 954579.87 8185.1 0.509391 0.809591 252.947 >> 1.48635e-08 >> 18 954579.88 8696.2 0.509391 0.809411 252.945 >> 1.31087e-08 >> 19 954579.9 9392.5 0.50939 0.80927 252.943 >> 1.3818e-08 >> Numerically Failed >> >> Did not converge in 19 iterations. >> >> >>>>> Did NOT converge (3.71 seconds) <<<<< >> >> 4) But when I used spy(J) , to look jacobian matrix it gives me some strange >> distribution. Herewith I attached image of jacobian matrix. ( I have modeled >> transmission lines and transformers to get one single branch matrix e.g. >> branch_matrix=vertcat(transmission_lines,grid_transformer) which is similar >> to matpower test cases.). So could you please suggest me what necessary >> steps I should follow? >> Thank you for your time. >> >> Regards >> Mirish Thakur >> KIT, University. >> >> On Mon, Aug 10, 2015 at 7:14 PM, Abhyankar, Shrirang G. <abhy...@anl.gov >> <mailto:abhy...@anl.gov>> wrote: >> I would suggest trying the following: >> >> Use the solution of a fast decoupled power flow or an optimal power flow >> (with line limits and voltage limits relaxed) as the initial guess for the >> power flow. >> Follow step 5 in http://www.pserc.cornell.edu/matpower/#pfconvergence >> <http://www.pserc.cornell.edu/matpower/#pfconvergence> making CPF to stop >> when the nose-point is reached. This can be done via results = >> runcpf(mpcbase,mpctarget,mpoption(‘cpf.stop_at’,’NOSE’)). If >> results.cpf.max_lam is >= 1, then it shows that the initial guess for the >> power flow is the problem for its divergence. To obtain a ‘good’ initial >> guess, run the continuation power flow again making it to stop exactly at >> lam = 1 (the target case loading and generation) via results = >> runcpf(mpcbase,mpctarget,mpoption(‘cpf.stop_at’,1.0)). You can then save the >> results struct as a matpower case file (via savecase()). On the other hand, >> if results.cpf.max_lam < 1, then the loading/generation in your original >> case is beyond the system steady-state loading limit. >> Shri >> From: Mirish Thakur <mirishtha...@gmail.com <mailto:mirishtha...@gmail.com>> >> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu >> <mailto:matpowe...@list.cornell.edu>> >> Date: Monday, August 10, 2015 at 10:44 AM >> To: MATPOWER discussion forum <matpowe...@list.cornell.edu >> <mailto:matpowe...@list.cornell.edu>> >> Subject: convergence problem in runpf. >> >> Dear Matpower Community, >> >> >> >> I’m working on power flow project and have used grid data from database. I >> have modelled all line parameters (R X B) in p.u. system, also same for >> transformers and kept generator output until it satisfies active and >> reactive power demand. For renewable generation, I specified as negative >> demand on respective buses. I checked all possibilities mentioned in FAQ >> (http://www.pserc.cornell.edu/matpower/#pfconvergence >> <http://www.pserc.cornell.edu/matpower/#pfconvergence> ) but couldn’t figure >> out problem. Also I checked (case_info) to see any island but got full >> system without island. To make the problem simple I used all buses as PQ >> buses except one slack bus. Also my casefile converges for rundcpf but fails >> to runpf and gives error like ‘Newton's method power flow did not converge >> in 10 iterations.’ Also I found that when I use following code- >> >> >> >> opt = mpoption('OUT_BUS', 0, 'OUT_BRANCH', 0, 'VERBOSE', 2); >> >> mpc = loadcase('casefile'); >> >> results =runpf(mpc,opt); >> >> >> may be it gives me divergence of PQ mismatch instead of convergence. >> >> >> >> MATPOWER Version 5.1, 20-Mar-2015 -- AC Power Flow (Newton) >> >> >> it max P & Q mismatch (p.u.) >> >> ---- --------------------------- >> >> 0 2.296e+01 >> >> 1 1.729e+01 >> >> 2 2.450e+03 >> >> 3 2.352e+03 >> >> 4 6.962e+06 >> >> 5 1.740e+06 >> >> 6 4.352e+05 >> >> 7 1.753e+07 >> >> 8 4.382e+06 >> >> 9 3.322e+06 >> >> 10 8.303e+05 >> >> Newton's method power flow did not converge in 10 iterations. >> >> >> >>>>> Did NOT converge (0.23 seconds) <<<<< >> >> >> >> results = >> >> version: '2' >> >> baseMVA: 100 >> >> bus: [1086x13 double] >> >> gen: [467x21 double] >> >> branch: [2145x17 double] >> >> order: [1x1 struct] >> >> et: 0.2320 >> >> success: 0 >> >> I will be very thankful for your help. >> >> >> Regards >> >> Mirish Thakur. >> >> KIT, University. >> >> >> >>
