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
On Fri, Aug 14, 2015 at 10:17 PM, Abhyankar, Shrirang G. <abhy...@anl.gov>
> 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
> 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.
> From: Jose Luis Marin <mari...@gridquant.com>
> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
> Date: Wednesday, August 12, 2015 at 2:42 AM
> To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
> Subject: Re: convergence problem in runpf.
> 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:
> 1. 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.
> 2. For the loads, start by zeroing out PD (real power demand), but
> keeping QD (reactive demand)
> 3. For generators, set the scheduled PG to zero
> 4. For lines & transformers, zero out the resistance R
> 5. 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.
> 6. 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
> 7. 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).
> 8. 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>
>> 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
>> 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-
>> 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
>> ---- ------------ --------- ------------ ------------ ------------
>> 0 1200199.7 2.41677 0.71 536.762
>> 1 946197.39 15.531 1.3682 1.75871 525.914
>> 2 954529.91 15.405 0.766107 0.203773 297.341
>> 3 954849.8 12.849 0.727712 0.0545952 258.471
>> 4 954629.03 13035 0.69114 0.107402 258.048
>> 5 954614.88 33406 0.692682 0.255673 257.828
>> 6 954525.69 14111 0.579613 0.143897 256.765
>> 7 954539.42 61648 0.581139 0.501345 255.994
>> 8 954518.93 22452 0.573652 0.478609 255.465
>> 9 954494.92 8540.4 0.556318 0.403754 254.653
>> 10 954523.58 20366 0.556265 0.570707 254.104
>> 11 954522.07 6142.4 0.554989 0.647881 256.561
>> 12 954573.42 6192.9 0.513972 0.716706 253.604
>> 13 954575.97 5912.1 0.509457 0.699751 252.612
>> 14 954576.23 16534 0.509454 0.674865 253.278
>> 15 954579.65 12324 0.509394 0.812237 252.966
>> 16 954579.86 7650.3 0.509391 0.80973 252.948
>> 17 954579.87 8185.1 0.509391 0.809591 252.947
>> 18 954579.88 8696.2 0.509391 0.809411 252.945
>> 19 954579.9 9392.5 0.50939 0.80927 252.943
>> 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.
>> Mirish Thakur
>> KIT, University.
>> On Mon, Aug 10, 2015 at 7:14 PM, Abhyankar, Shrirang G. <abhy...@anl.gov>
>>> I would suggest trying the following:
>>> 1. 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.
>>> 2. Follow step 5 in
>>> 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.
>>> From: Mirish Thakur <mirishtha...@gmail.com>
>>> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
>>> Date: Monday, August 10, 2015 at 10:44 AM
>>> To: MATPOWER discussion forum <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 ) 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.
>>> Mirish Thakur.
>>> KIT, University.