Re: convergence problem in runpf.
Hello MatPower community, I want to analyze monetary consequences of reactive power dispatch on energy market which is already considering real power prices only. For this I have data of conventional power plants dispatch for every hour in whole year and respective variable cost of generation. I’ve active and reactive power demand for each hour as well. For this case I want to keep generator dispatch Pg=Pmin=Pmax (no change in active power generation) and Pd and Qd (real and reactive demand) as per given for whole year. Also I want to keep RATE_A value constant in opf. But I’m facing convergence problem in runopf. runopf doesn’t converge until and unless I make Rate_A value 1.5 times and some changes in Pmax and Pmin values at input side. Is there any alternate way to get convergence without making any changes in Pg, Pmax, Pmin and Rate_A value? (For example any changes in line parameters or something else). Thank you for your time. Regards Mirish Thakur KIT University. On Thu, Sep 17, 2015 at 9:27 PM, Ray Zimmerman <r...@cornell.edu> wrote: > 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> > 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> > 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 >> (l
Re: convergence problem in runpf.
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 >> &l
Re: convergence problem in runpf.
Thank you. On Aug 15, 2015, at 12:06 PM, Jose Luis Marin mari...@gridquant.commailto: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.govmailto: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.commailto:mari...@gridquant.com Reply-To: MATPOWER discussion forum matpowe...@list.cornell.edumailto:matpowe...@list.cornell.edu Date: Wednesday, August 12, 2015 at 2:42 AM To: MATPOWER discussion forum matpowe...@list.cornell.edumailto: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 RX), 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.commailto: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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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) itobjective step size feascond gradcond compcond costcond - 0 1200199.7 2.41677 0.71 536.7620 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.7277120.0545952 258.471 0.00033166 4
Re: convergence problem in runpf.
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 RX), 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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=newest
https://www.mail-archive.com/search?l=matpower-l@cornell.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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)
itobjective 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.7277120.0545952 258.471
0.00033166
4 954629.03 13035 0.69114 0.107402
Re: convergence problem in runpf.
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.commailto:mari...@gridquant.com Reply-To: MATPOWER discussion forum matpowe...@list.cornell.edumailto:matpowe...@list.cornell.edu Date: Wednesday, August 12, 2015 at 2:42 AM To: MATPOWER discussion forum matpowe...@list.cornell.edumailto: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 RX), 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.commailto: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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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) itobjective step size feascond gradcond compcond costcond - 0 1200199.7 2.41677 0.71 536.7620 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.7277120.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
Re: convergence problem in runpf.
Dear Jose and Shree,
Thank you very much for your guidance. I followed the step as you suggested
and runpf converged in 8 iterations. Actually there were three PQ buses
which had excessive Q demand and when I reduced the Q demand for those
buses then it converged properly.
Nice regards
Mirish Thakur
KIT University.
On Wed, Aug 12, 2015 at 9:42 AM, Jose Luis Marin mari...@gridquant.com
wrote:
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 RX), 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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=newest
https://www.mail-archive.com/search?l=matpower-l@cornell.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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)
itobjective 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.7277120.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
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 RX), 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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=newest
https://www.mail-archive.com/search?l=matpower-l@cornell.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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)
itobjective 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.7277120.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
Re: convergence problem in runpf.
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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=newest https://www.mail-archive.com/search?l=matpower-l@cornell.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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) itobjective 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.7277120.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
Re: convergence problem in runpf.
Unfortunately, I can’t say anything about the divergence of the power flow by looking at the Jacobian spy plot. The Jacobian spy plot looks fine to me based on how the equations and variables are ordered for MATPOWER’s power flow. Please send me the test case (offline) and I’ll try to debug further. Shri You could also try to check whether your case is insolvable http://www.pserc.cornell.edu/Matpower/docs/ref/matpower5.1/extras/sdp_pf/insolvablepfsos.html From: Mirish Thakur mirishtha...@gmail.commailto:mirishtha...@gmail.com Reply-To: MATPOWER discussion forum matpowe...@list.cornell.edumailto:matpowe...@list.cornell.edu Date: Tuesday, August 11, 2015 at 7:36 PM To: MATPOWER discussion forum matpowe...@list.cornell.edumailto:matpowe...@list.cornell.edu Subject: Re: convergence problem in runpf. 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.eduq=subject:%22Re%5C%3A+%5C%5BMatpower%5C%5D+3500+bus+simulation%22o=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) itobjective step size feascond gradcond compcond costcond - 0 1200199.7 2.41677 0.71 536.7620 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.7277120.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.govmailto: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
Re: convergence problem in runpf.
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.commailto:mirishtha...@gmail.com
Reply-To: MATPOWER discussion forum
matpowe...@list.cornell.edumailto:matpowe...@list.cornell.edu
Date: Monday, August 10, 2015 at 10:44 AM
To: MATPOWER discussion forum
matpowe...@list.cornell.edumailto: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)
itmax 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.
Re: Convergence problem in runpf for contingency
Dear Jose L. Marin and Dr.Zimmerman, Thank you Mr.Jose L. Marin for your detailed explanations. I also thank Dr.Zimmerman for giving hint in using find_islands() function. Regards, Babulal On 31-10-2014 18:15, Jose Luis Marin wrote: Hello Babulal, I believe that the problem is that MATPOWER does not automatically remove islands when running a powerflow. Each of the three contingencies you list happen to isolate a bus, therefore the network needs to be reduced prior to the call to runpf (Ray -- please correct me if I'm wrong). You can use extract_islands() for this: mpc = loadcase(IEEE30_Conting9_11) mpc = version: '2' baseMVA: 100 bus: [30x13 double] gen: [6x25 double] branch: [41x13 double] mpc_reduced = extract_islands(mpc, 1) mpc_reduced = version: '2' baseMVA: 100 bus: [29x13 double] gen: [5x25 double] branch: [40x13 double] Running runpf() on this reduced case works OK for the contingencies you list. -- Jose L. Marin Gridquant España SL Grupo AIA On Fri, Oct 31, 2014 at 9:41 AM, ckbeee ckb...@tce.edu wrote: Dear Dr.Zimmerman, When I perform the power flow for the following contingency in case_ieee30.m system, MATPOWER experiences numerical instability. 1. Line number 13 (Connected between buses 9-11) 2. Line number 16 (Connected between buses 13-12) 3. Line number 34 (Connected between buses 25-26) It means no solution exist for these contingencies. It does not give results for OPF also. Thanks in advance. Regards, Babulal -- Assistant Professor Department of Electrical and Electronics Engineering Thiagarajar College of Engineering. Madurai-625 015. Tamilnadu. India. Mobile: +91 98439 17258 [1] ck_babu...@gmail.com -- This email was sent using TCEMail Service. Thiagarajar College of Engineering Madurai-625 015, India -- Assistant Professor Department of Electrical and Electronics Engineering Thiagarajar College of Engineering. Madurai-625 015. Tamilnadu. India. Mobile: +91 98439 17258 ck_babu...@gmail.com -- This email was sent using TCEMail Service. Thiagarajar College of Engineering Madurai-625 015, India Links: -- [1] tel:%2B91%2098439%2017258
Re: Convergence problem in runpf for contingency
Hello Babulal, I believe that the problem is that MATPOWER does not automatically remove islands when running a powerflow. Each of the three contingencies you list happen to isolate a bus, therefore the network needs to be reduced prior to the call to runpf (Ray -- please correct me if I'm wrong). You can use extract_islands() for this: mpc = loadcase(IEEE30_Conting9_11) mpc = version: '2' baseMVA: 100 bus: [30x13 double] gen: [6x25 double] branch: [41x13 double] mpc_reduced = extract_islands(mpc, 1) mpc_reduced = version: '2' baseMVA: 100 bus: [29x13 double] gen: [5x25 double] branch: [40x13 double] Running runpf() on this reduced case works OK for the contingencies you list. -- Jose L. Marin Gridquant España SL Grupo AIA On Fri, Oct 31, 2014 at 9:41 AM, ckbeee ckb...@tce.edu wrote: Dear Dr.Zimmerman, When I perform the power flow for the following contingency in case_ieee30.m system, MATPOWER experiences numerical instability. 1. Line number 13 (Connected between buses 9-11) 2. Line number 16 (Connected between buses 13-12) 3. Line number 34 (Connected between buses 25-26) It means no solution exist for these contingencies. It does not give results for OPF also. Thanks in advance. Regards, Babulal -- Assistant Professor Department of Electrical and Electronics Engineering Thiagarajar College of Engineering. Madurai-625 015. Tamilnadu. India. Mobile: +91 98439 17258 ck_babu...@gmail.com -- This email was sent using TCEMail Service. Thiagarajar College of Engineering Madurai-625 015, India
