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>
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
> 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>
> 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.
>
> 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:
>
>    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
>    wrong.
>    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>
> 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
>> 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>
>> wrote:
>>
>>> 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.
>>>
>>> Shri
>>> 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.
>>>
>>>
>>> Regards
>>>
>>> Mirish Thakur.
>>>
>>> KIT, University.
>>>
>>>
>>
>

Reply via email to