Re: Power Flow Calculation Error

[Ray Daniel Zimmerman]

It will be included in the next MATPOWER release (planned to be 8.0).

But, if you want to use the updated version now, you can either …
1) clone/download and install the current MATPOWER master 
branch (to download, click the green 
“Code” button, then select “Download ZIP”), or
2) download the latest 
radial_pf.m 
(and 
t/t_pf_radial.m)
 and replace the corresponding files in your current MATPOWER 7.1 distribution.

   Ray


On Dec 5, 2023, at 11:11 PM, Muhammad Junaid  wrote:

With reference to issue 210, 
how can we utilize the updated file? Will it be integrated into MATPOWER 7.1, 
or do we need to download the updated radial.pf separately?

On Wed, Nov 22, 2023 at 10:16 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
What you show is a warning (not an error) coming from the Power Summation 
method. As long is the method converges with success = 1, the result should be 
valid.

Also, if the Newton power flow converges, its result should also be fine. 
Sometimes the Newton power flow has more difficulty on distribution systems, 
but it depends on the case.

Ray


On Nov 18, 2023, at 6:29 AM, Muhammad Junaid 
mailto:gaylethunder...@gmail.com>> wrote:

Hi Sir,

I hope you are doing well. Sir, when we use this data for the generator matrix, 
it gets solved using Newton's Power Flow but gives this error:
MATPOWER Version 7.1, 08-Oct-2020 -- AC Power Flow (Power Summation)
Warning: Matrix is singular to working precision.
> In calc_v_pq_sum (line 53)
  In radial_pf (line 63)
  In runpf (line 283)
  In Code (line 118)
Power summation did not converge in 20 iterations when using the 
Forward-Backward Sweep method. I have considered the case33bw distribution 
network. Shouldn't the Forward-Backward Sweep method be better able to solve 
this network, considering it is a distribution network? Or is Newton's Power 
Flow modified to accurately solve radial networks as well?

Re: Power Flow Calculation Error

[Muhammad Junaid]

With reference to issue 210
, how can we utilize the
updated file? Will it be integrated into MATPOWER 7.1, or do we need to
download the updated radial.pf separately?

On Wed, Nov 22, 2023 at 10:16 PM Ray Daniel Zimmerman 
wrote:

> What you show is a warning (not an error) coming from the Power Summation
> method. As long is the method converges with success = 1, the result should
> be valid.
>
> Also, if the Newton power flow converges, its result should also be fine.
> Sometimes the Newton power flow has more difficulty on distribution
> systems, but it depends on the case.
>
> Ray
>
>
> On Nov 18, 2023, at 6:29 AM, Muhammad Junaid 
> wrote:
>
> Hi Sir,
>
> I hope you are doing well. Sir, when we use this data for the generator
> matrix, it gets solved using Newton's Power Flow but gives this error:
>
>> MATPOWER Version 7.1, 08-Oct-2020 -- AC Power Flow (Power Summation)
>> Warning: Matrix is singular to working precision.
>> > In calc_v_pq_sum (line 53)
>>   In radial_pf (line 63)
>>   In runpf (line 283)
>>   In Code (line 118)
>>
> Power summation did not converge in 20 iterations when using the
> Forward-Backward Sweep method. I have considered the case33bw distribution
> network. Shouldn't the Forward-Backward Sweep method be better able to
> solve this network, considering it is a distribution network? Or is
> Newton's Power Flow modified to accurately solve radial networks as well?
> 
>
>
>

Re: Power Flow Calculation Error

[Ray Daniel Zimmerman]

What you show is a warning (not an error) coming from the Power Summation 
method. As long is the method converges with success = 1, the result should be 
valid.

Also, if the Newton power flow converges, its result should also be fine. 
Sometimes the Newton power flow has more difficulty on distribution systems, 
but it depends on the case.

Ray


On Nov 18, 2023, at 6:29 AM, Muhammad Junaid  wrote:

Hi Sir,

I hope you are doing well. Sir, when we use this data for the generator matrix, 
it gets solved using Newton's Power Flow but gives this error:
MATPOWER Version 7.1, 08-Oct-2020 -- AC Power Flow (Power Summation)
Warning: Matrix is singular to working precision.
> In calc_v_pq_sum (line 53)
  In radial_pf (line 63)
  In runpf (line 283)
  In Code (line 118)
Power summation did not converge in 20 iterations when using the 
Forward-Backward Sweep method. I have considered the case33bw distribution 
network. Shouldn't the Forward-Backward Sweep method be better able to solve 
this network, considering it is a distribution network? Or is Newton's Power 
Flow modified to accurately solve radial networks as well?

Re: Power Flow Calculation Error

[Ray Daniel Zimmerman]

I didn’t write the code for the power summation method, so I wasn’t aware that 
it did not handle multiple generators at a single bus. I consider this a bug. 
Would you mind creating a bug report for it 
here?

Thanks,

 Ray


On Nov 18, 2023, at 6:37 AM, Muhammad Junaid  wrote:

When the generator matrix has the same bus numbers for new rows (other 
generators placed on the same bus) it gives an error for the power summation 
method. However, if we add those P and Q's to the same bus for multiple DG's P 
and Q and represent it as a single bus then it doesn't give an error.

On Sat, Nov 18, 2023 at 6:29 PM Muhammad Junaid 
mailto:gaylethunder...@gmail.com>> wrote:
Hi Sir,

I hope you are doing well. Sir, when we use this data for the generator matrix, 
it gets solved using Newton's Power Flow but gives this error:
MATPOWER Version 7.1, 08-Oct-2020 -- AC Power Flow (Power Summation)
Warning: Matrix is singular to working precision.
> In calc_v_pq_sum (line 53)
  In radial_pf (line 63)
  In runpf (line 283)
  In Code (line 118)
Power summation did not converge in 20 iterations when using the 
Forward-Backward Sweep method. I have considered the case33bw distribution 
network. Shouldn't the Forward-Backward Sweep method be better able to solve 
this network, considering it is a distribution network? Or is Newton's Power 
Flow modified to accurately solve radial networks as well?

Re: Power Flow Calculation Error

[Muhammad Junaid]

When the generator matrix has the same bus numbers for new rows (other
generators placed on the same bus) it gives an error for the power
summation method. However, if we add those P and Q's to the same bus for
multiple DG's P and Q and represent it as a single bus then it doesn't give
an error.

On Sat, Nov 18, 2023 at 6:29 PM Muhammad Junaid 
wrote:

> Hi Sir,
>
> I hope you are doing well. Sir, when we use this data for the generator
> matrix, it gets solved using Newton's Power Flow but gives this error:
>
>> MATPOWER Version 7.1, 08-Oct-2020 -- AC Power Flow (Power Summation)
>> Warning: Matrix is singular to working precision.
>> > In calc_v_pq_sum (line 53)
>>   In radial_pf (line 63)
>>   In runpf (line 283)
>>   In Code (line 118)
>>
> Power summation did not converge in 20 iterations when using the
> Forward-Backward Sweep method. I have considered the case33bw distribution
> network. Shouldn't the Forward-Backward Sweep method be better able to
> solve this network, considering it is a distribution network? Or is
> Newton's Power Flow modified to accurately solve radial networks as well?
> [image: image.png]
>

Re: Power flow and generation power limit

[Dr. D. Karthikaikannan .]

I mean Pmin and Pmax is not accounted in load flow analysis.

On Sat, 11 Feb 2023, 9:10 am Dr. D. Karthikaikannan ., <
karthikaikan...@eee.sastra.edu> wrote:

> Load flow analysis do not take real power constraints. Reactive power
> constraints you can include for generations.
>
> On Sat, 11 Feb 2023, 4:29 am Muhammad Nadeem,  wrote:
>
>> Hello everyone,
>>
>> I am a bit new to MATPOWER, I am bit confused about the working of
>> "runpf()" command. Does it checks the active and reactive power generation
>> limit constraints of synchronous generator? Because as a test case i
>> decrease the Pmax on generations but still runpf() converges although the
>> available capacity of generations are not met. Please see the screenshot
>> below.
>>
>> Any help will be appreciated,
>>
>>
>> Thank you,
>> Nadeem
>>
>

Re: Power flow and generation power limit

[Dr. D. Karthikaikannan .]

Load flow analysis do not take real power constraints. Reactive power
constraints you can include for generations.

On Sat, 11 Feb 2023, 4:29 am Muhammad Nadeem,  wrote:

> Hello everyone,
>
> I am a bit new to MATPOWER, I am bit confused about the working of
> "runpf()" command. Does it checks the active and reactive power generation
> limit constraints of synchronous generator? Because as a test case i
> decrease the Pmax on generations but still runpf() converges although the
> available capacity of generations are not met. Please see the screenshot
> below.
>
> Any help will be appreciated,
>
>
> Thank you,
> Nadeem
>

Re: Power flow calculation when changing the network topology

[Ahmad Sadiq Abubakar]

Dear Yan,

Yes to your first question. The STATUS determine the connectivity or
otherwise of a branch.

On the second question, there are algorithm for running Distribution power
flow different from runpf.

Kindly refer to the manual for about three different distribution power
flow algorithm and how they are invoked.

Lastly, not all reconfigured topology may necessarily converged even with
distribution power flow algorithm. So, be sure while implementing the
reconfiguration, you don't create Island..

Hope this helps. Regards.

On Sat, Apr 30, 2022, 5:30 PM Ziheng Yan  wrote:

> Dears,
>
>I‘m trying to calculate power flow in distribution systems considering
> network reconfiguration. From the data format description, I noticed that
> the 11th column of mpc.branch named BR_STATUS represents "initial branch
> status". But I'm not sure whether that attribute means the on/off status of
> branches and thus determines the network topology. Take 'case33bw' as an
> example, when I was trying to change the 11th column of mpc.branch (network
> connectivity and radiality is guaranteed) and execute runpf, the power flow
> calculation fails to converge in some network topology (success=0 and it
> reaches max iterations). I have tried several power flow algorithms as well
> as increase the max number of iterations, but all fails. So the question
> I'm gonna ask is:
>
>1) While doing power flow calculation, does BR_STATUS determine the
> network topology?
>2) Any suggestions for cases where power flow cannot converge?
>
>Thank you in advance, early reply is appreciated.
>
>
> Regards,
> Yan
>
>
>
>

Re: Power flow while involving radial systems

[赤心 肖]

Hi Aamir Nawaz,
   Thanks a lot. It is also useful for me.
With kind regards,
Chixin

From: bounce-123871516-44420...@list.cornell.edu 
 on behalf of Aamir Nawaz 

Sent: 02 September 2019 14:53
To: MATPOWER discussion forum 
Subject: Re: Power flow while involving radial systems

Dear Chixin Xiao,
if you have executed it already, the avoid this message. Otherwise i have 
attached corrected case30 combined with case33.
Regards,
Aamir Nawaz

On Mon, Sep 2, 2019 at 12:33 PM 赤心 肖 
mailto:chixinx...@hotmail.com>> wrote:
Hi Prof.Ray,
 I found the mistake that I forgot to transfer the W to KW while combining 
two systems. Thanks.
Regards,
Chixin

From: 
bounce-123871453-44420...@list.cornell.edu<mailto:bounce-123871453-44420...@list.cornell.edu>
 
mailto:bounce-123871453-44420...@list.cornell.edu>>
 on behalf of chixinx...@hotmail.com<mailto:chixinx...@hotmail.com> 
mailto:chixinx...@hotmail.com>>
Sent: 02 September 2019 14:01
To: 'MATPOWER discussion forum' 
mailto:matpowe...@list.cornell.edu>>
Subject: Power flow while involving radial systems

Dear Prof.Ray,
   The runpf and the runopf did not converge while handling a revised system 
(i.e., IEEE 30 and IEEE 33).  The revised system is attached.  Could you give 
me some suggestions when you feel convenient? Thanks.
   The revising details:  a standard IEEE 30 bus system [] is revised by 
connecting the bus 2 to the bus 1 of an IEEE 33-bus radial system [] which 
consists of 33 buses, 32 lines,  a  voltage  of  12.66kV,  load  size  of  
3.715MW  and 2.3MVar.
 In the new combined system, the original bus-index  of the IEEE 33-bus has 
increased 30 (i.e., the original bus-index 1 corresponds the new index 31, and 
so on). The resistance and reactance between bus 1 and bus 31 are 0.2030 (p.u.) 
and 0.1034 (p.u.) respectively.
Regards,
Chixin

Re: Power flow while involving radial systems

[Aamir Nawaz]

Dear Chixin Xiao,
if you have executed it already, the avoid this message. Otherwise i have
attached corrected case30 combined with case33.
*Regards,*

*Aamir Nawaz*

On Mon, Sep 2, 2019 at 12:33 PM 赤心 肖  wrote:

> Hi Prof.Ray,
>  I found the mistake that I forgot to transfer the W to KW while
> combining two systems. Thanks.
> Regards,
> Chixin
> --
> *From:* bounce-123871453-44420...@list.cornell.edu <
> bounce-123871453-44420...@list.cornell.edu> on behalf of
> chixinx...@hotmail.com 
> *Sent:* 02 September 2019 14:01
> *To:* 'MATPOWER discussion forum' 
> *Subject:* Power flow while involving radial systems
>
> Dear Prof.Ray,
>The runpf and the runopf did not converge while handling a revised
> system (i.e., IEEE 30 and IEEE 33).  The revised system is attached.  Could
> you give me some suggestions when you feel convenient? Thanks.
>The revising details:  a standard IEEE 30 bus system [] is revised by
> connecting the bus 2 to the bus 1 of an IEEE 33-bus radial system [] which
> consists of 33 buses, 32 lines,  a  voltage  of  12.66kV,  load  size  of
>  3.715MW  and 2.3MVar.
>  In the new combined system, the original bus-index  of the IEEE
> 33-bus has increased 30 (i.e., the original bus-index 1 corresponds the new
> index 31, and so on). The resistance and reactance between bus 1 and bus 31
> are 0.2030 (p.u.) and 0.1034 (p.u.) respectively.
> Regards,
> Chixin
>


case30_RS33_XIAO.m
Description: Binary data

Re: Power flow while involving radial systems

[赤心 肖]

Hi Prof.Ray,
 I found the mistake that I forgot to transfer the W to KW while combining 
two systems. Thanks.
Regards,
Chixin

From: bounce-123871453-44420...@list.cornell.edu 
 on behalf of 
chixinx...@hotmail.com 
Sent: 02 September 2019 14:01
To: 'MATPOWER discussion forum' 
Subject: Power flow while involving radial systems

Dear Prof.Ray,
   The runpf and the runopf did not converge while handling a revised system 
(i.e., IEEE 30 and IEEE 33).  The revised system is attached.  Could you give 
me some suggestions when you feel convenient? Thanks.
   The revising details:  a standard IEEE 30 bus system [] is revised by 
connecting the bus 2 to the bus 1 of an IEEE 33-bus radial system [] which 
consists of 33 buses, 32 lines,  a  voltage  of  12.66kV,  load  size  of  
3.715MW  and 2.3MVar.
 In the new combined system, the original bus-index  of the IEEE 33-bus has 
increased 30 (i.e., the original bus-index 1 corresponds the new index 31, and 
so on). The resistance and reactance between bus 1 and bus 31 are 0.2030 (p.u.) 
and 0.1034 (p.u.) respectively.
Regards,
Chixin

Re: power flow with forward backward sweep algorithm for radial system

[amir ali Hosseini]

thanks a lot

On Wed, May 1, 2019 at 4:14 PM Ilias Sarantakos 
wrote:

> Hi Amir,
>
> The latest version of MATPOWER (7.0b1) includes three new power flow
> algorithms for radial distribution systems selected via the three new
> options for pf.alg, namely 'PQSUM', 'ISUM', 'YSUM'.
>
> Kind regards,
>
> Ilias
>
> Ilias Sarantakos
> PhD Student
> Newcastle University, UK
>
> Στις Τετ, 1 Μαΐ 2019 στις 8:16 π.μ., ο/η amir ali Hosseini <
> tpmhosse...@gmail.com> έγραψε:
>
>> hi dears !
>> i need  flow with forward backward sweep algorithm for radial system .
>> is MATPOWER has a code ,? same runpf  that doing load flow  with neoton
>> method?
>> thanks a lot
>>
>>

Re: power flow with forward backward sweep algorithm for radial system

[Ilias Sarantakos]

Hi Amir,

The latest version of MATPOWER (7.0b1) includes three new power flow
algorithms for radial distribution systems selected via the three new
options for pf.alg, namely 'PQSUM', 'ISUM', 'YSUM'.

Kind regards,

Ilias

Ilias Sarantakos
PhD Student
Newcastle University, UK

Στις Τετ, 1 Μαΐ 2019 στις 8:16 π.μ., ο/η amir ali Hosseini <
tpmhosse...@gmail.com> έγραψε:

> hi dears !
> i need  flow with forward backward sweep algorithm for radial system .
> is MATPOWER has a code ,? same runpf  that doing load flow  with neoton
> method?
> thanks a lot
>
>

Re: power flow problem

[Mohamed Shaheen]

Many thanks. I will try and if I needed more help, I will ask you

On Mon, Feb 11, 2019, 4:19 PM Carlos E Murillo-Sanchez <
ce.murillosanc...@gmail.com wrote:

> Therein lies the problem.  Your optimization procedure, as formulated, has
> no say on the resulting voltages.   I can think of two suggestions for
> dealing with this:
>
> 1) Instead of a power flow, use an OPF with all non-slack generators'
> active power outputs fixed to whatever values were assigned by the
> optimization algorithm at the current iteration (set Pmin=Pg=Pmax for those
> generators).  What this will do is essentially a reactive redispatch which
> will try to comply with voltage limits, generation limits and transmission
> limits.  You can expect the slack generation to vary a little bit to
> compensate for the differing amount of losses.
>
> 2) Include the reactive generation variables in your formulation and
> continue using a simple load flow.
>
> carlos.
>
> Mohamed Shaheen wrote:
>
> No, I don't
>
> On Sun, Feb 10, 2019, 1:24 AM Carlos E Murillo-Sanchez <
> ce.murillosanc...@gmail.com wrote:
>
>> Do you include reactive generation in the decision variables of your
>> formulation?  If you don't, then your optimization algorithm does not
>> really have much impact on voltages.
>>
>> carlos.
>>
>> Mohamed Shaheen wrote:
>>
>> I'm currently using penalty functions with GA and Tree-Seed, But after
>> running Tree-Seed algorithm including 'runpf' inside, All solutions have
>> violations and the algorithm chooses the minimum of these solutions which
>> is also a false solution.
>> ᐧ
>>
>> On Sat, 9 Feb 2019 at 15:42, Carlos E Murillo-Sanchez <
>> ce.murillosanc...@gmail.com> wrote:
>>
>>> Rather, it seems that your optimization method should take into account
>>> any constraint violation and fix the issue by itself.  In some methods,
>>> such as GA, one way to do this is by using penalty functions on constraint
>>> violations.
>>>
>>> carlos.
>>>
>>>
>>> Mohamed Shaheen wrote:
>>>
>>> I need to enforce limits, but I aim to get the optimal solution and best
>>> parameters using another optimization method called 'Tree Seed' and compare
>>> it with 'Genetic Algorithm' after running normal power flow, So I'm not
>>> seeking the optimal solution using Matpower itself.
>>> Can Matpower help to do this?
>>>
>>> ᐧ
>>>
>>> On Fri, 8 Feb 2019 at 23:53, Ray Zimmerman  wrote:
>>>
 The power flow problem solved by runpf does not take into account
 voltage limits. If you need to enforce limits, you can use an appropriately
 constrained OPF.

 In this case, it just so happens that the initial voltage specified for
 bus 31 in the case57.m file happens to be the voltage at the power flow
 solution.

 Ray


 On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen <
 mohamed.shaheen9...@gmail.com> wrote:

 Dear Sir,

 Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less
 than the min. limit of bus voltage (0.94). Every time I run 'runpf', the
 voltage value is 0.936 and it doesn't change although it is a PQ bus.
 I need your help, please.

 Regards,
 Mohamed Shaheen.

 Msc. student at Ain Shams University in Egypt
 Teaching Assistant in Future University in Egypt
 ᐧ



>>>
>>
>

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Therein lies the problem.  Your
  optimization procedure, as formulated, has no say on the resulting
  voltages.   I can think of two suggestions for dealing with this:
  
  1) Instead of a power flow, use an OPF with all non-slack
  generators' active power outputs fixed to whatever values were
  assigned by the optimization algorithm at the current iteration
  (set Pmin=Pg=Pmax for those generators).  What this will do is
  essentially a reactive redispatch which will try to comply with
  voltage limits, generation limits and transmission limits.  You
  can expect the slack generation to vary a little bit to compensate
  for the differing amount of losses.
  
  2) Include the reactive generation variables in your formulation
  and continue using a simple load flow.
  
  carlos.
  
  Mohamed Shaheen wrote:


  No, I don't
  
  
On Sun, Feb 10, 2019, 1:24 AM Carlos E
  Murillo-Sanchez 
  wrote:


  
Rather,
  it seems that your optimization method should take
  into account any constraint violation and fix the
  issue by itself.  In some methods, such as GA, one
  way to do this is by using penalty functions on
  constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim
to get the optimal solution and best parameters
using another optimization method called 'Tree
Seed' and compare it with 'Genetic Algorithm'
after running normal power flow, So I'm not
seeking the optimal solution using
Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb
  2019 at 23:53, Ray Zimmerman 
  wrote:


  The power flow problem solved by runpf does not take
into account voltage limits. If you need to
enforce limits, you can use an appropriately
constrained OPF.


In this case, it just so happens that
  the initial voltage specified for bus 31
  in the case57.m file happens to be the
  voltage at the power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM,
Mohamed Shaheen 
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the
voltage of bus 31 is 0.936 p.u
which is less than the min.
limit of bus voltage (0.94).
Every time I run 'runpf', the
voltage value is 0.936 and it
 

Re: power flow problem

[Mohamed Shaheen]

No, I don't

On Sun, Feb 10, 2019, 1:24 AM Carlos E Murillo-Sanchez <
ce.murillosanc...@gmail.com wrote:

> Do you include reactive generation in the decision variables of your
> formulation?  If you don't, then your optimization algorithm does not
> really have much impact on voltages.
>
> carlos.
>
> Mohamed Shaheen wrote:
>
> I'm currently using penalty functions with GA and Tree-Seed, But after
> running Tree-Seed algorithm including 'runpf' inside, All solutions have
> violations and the algorithm chooses the minimum of these solutions which
> is also a false solution.
> ᐧ
>
> On Sat, 9 Feb 2019 at 15:42, Carlos E Murillo-Sanchez <
> ce.murillosanc...@gmail.com> wrote:
>
>> Rather, it seems that your optimization method should take into account
>> any constraint violation and fix the issue by itself.  In some methods,
>> such as GA, one way to do this is by using penalty functions on constraint
>> violations.
>>
>> carlos.
>>
>>
>> Mohamed Shaheen wrote:
>>
>> I need to enforce limits, but I aim to get the optimal solution and best
>> parameters using another optimization method called 'Tree Seed' and compare
>> it with 'Genetic Algorithm' after running normal power flow, So I'm not
>> seeking the optimal solution using Matpower itself.
>> Can Matpower help to do this?
>>
>> ᐧ
>>
>> On Fri, 8 Feb 2019 at 23:53, Ray Zimmerman  wrote:
>>
>>> The power flow problem solved by runpf does not take into account
>>> voltage limits. If you need to enforce limits, you can use an appropriately
>>> constrained OPF.
>>>
>>> In this case, it just so happens that the initial voltage specified for
>>> bus 31 in the case57.m file happens to be the voltage at the power flow
>>> solution.
>>>
>>> Ray
>>>
>>>
>>> On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen <
>>> mohamed.shaheen9...@gmail.com> wrote:
>>>
>>> Dear Sir,
>>>
>>> Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less
>>> than the min. limit of bus voltage (0.94). Every time I run 'runpf', the
>>> voltage value is 0.936 and it doesn't change although it is a PQ bus.
>>> I need your help, please.
>>>
>>> Regards,
>>> Mohamed Shaheen.
>>>
>>> Msc. student at Ain Shams University in Egypt
>>> Teaching Assistant in Future University in Egypt
>>> ᐧ
>>>
>>>
>>>
>>
>

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Do you include reactive generation in
  the decision variables of your formulation?  If you don't, then
  your optimization algorithm does not really have much impact on
  voltages.
  
  carlos.
  
  Mohamed Shaheen wrote:


  I'm currently using penalty functions with GA and
Tree-Seed, But after running Tree-Seed algorithm including
'runpf' inside, All solutions have violations and the algorithm
chooses the minimum of these solutions which is also a false
solution. 
  ᐧ
  
  
On Sat, 9 Feb 2019 at 15:42,
  Carlos E Murillo-Sanchez 
  wrote:


  
Rather,
  it seems that your optimization method should take into
  account any constraint violation and fix the issue by
  itself.  In some methods, such as GA, one way to do this
  is by using penalty functions on constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim to get
the optimal solution and best parameters using another
optimization method called 'Tree Seed' and compare it
with 'Genetic Algorithm' after running normal power
flow, So I'm not seeking the optimal solution using
Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb 2019 at
  23:53, Ray Zimmerman 
  wrote:


  The power flow problem solved by runpf does not take into
account voltage limits. If you need to enforce
limits, you can use an appropriately constrained
OPF.


In this case, it just so happens that the
  initial voltage specified for bus 31 in the
  case57.m file happens to be the voltage at the
  power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM, Mohamed
Shaheen 
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the voltage of
bus 31 is 0.936 p.u which is less than
the min. limit of bus voltage (0.94).
Every time I run 'runpf', the voltage
value is 0.936 and it doesn't change
although it is a PQ bus.
  I need your help, please.   
  
  
  
  Regards,
  Mohamed Shaheen.
  
  
  Msc. student at Ain Shams University
in Egypt
  Teaching Assistant in Future
University in Egypt

ᐧ
  

  
  

  

  


  

  


  

Re: power flow problem

[Mohamed Shaheen]

I'm currently using penalty functions with GA and Tree-Seed, But after
running Tree-Seed algorithm including 'runpf' inside, All solutions have
violations and the algorithm chooses the minimum of these solutions which
is also a false solution.
ᐧ

On Sat, 9 Feb 2019 at 15:42, Carlos E Murillo-Sanchez <
ce.murillosanc...@gmail.com> wrote:

> Rather, it seems that your optimization method should take into account
> any constraint violation and fix the issue by itself.  In some methods,
> such as GA, one way to do this is by using penalty functions on constraint
> violations.
>
> carlos.
>
>
> Mohamed Shaheen wrote:
>
> I need to enforce limits, but I aim to get the optimal solution and best
> parameters using another optimization method called 'Tree Seed' and compare
> it with 'Genetic Algorithm' after running normal power flow, So I'm not
> seeking the optimal solution using Matpower itself.
> Can Matpower help to do this?
>
> ᐧ
>
> On Fri, 8 Feb 2019 at 23:53, Ray Zimmerman  wrote:
>
>> The power flow problem solved by runpf does not take into account
>> voltage limits. If you need to enforce limits, you can use an appropriately
>> constrained OPF.
>>
>> In this case, it just so happens that the initial voltage specified for
>> bus 31 in the case57.m file happens to be the voltage at the power flow
>> solution.
>>
>> Ray
>>
>>
>> On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen <
>> mohamed.shaheen9...@gmail.com> wrote:
>>
>> Dear Sir,
>>
>> Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less
>> than the min. limit of bus voltage (0.94). Every time I run 'runpf', the
>> voltage value is 0.936 and it doesn't change although it is a PQ bus.
>> I need your help, please.
>>
>> Regards,
>> Mohamed Shaheen.
>>
>> Msc. student at Ain Shams University in Egypt
>> Teaching Assistant in Future University in Egypt
>> ᐧ
>>
>>
>>
>

Re: power flow problem

[Carlos E Murillo-Sanchez]

  
  
Rather, it seems that your optimization
  method should take into account any constraint violation and fix
  the issue by itself.  In some methods, such as GA, one way to do
  this is by using penalty functions on constraint violations.
  
  carlos.
  
  
  Mohamed Shaheen wrote:


  I need to enforce limits, but I aim to get the
optimal solution and best parameters using another optimization
method called 'Tree Seed' and compare it with 'Genetic
Algorithm' after running normal power flow, So I'm not seeking
the optimal solution using Matpower itself.
Can Matpower help to do this? 


  
  ᐧ
  
  
On Fri, 8 Feb 2019 at 23:53,
  Ray Zimmerman  wrote:


  The power flow problem
solved by runpf does not take
into account voltage limits. If you need to enforce limits,
you can use an appropriately constrained OPF.


In this case, it just so happens that the initial
  voltage specified for bus 31 in the case57.m file happens
  to be the voltage at the power flow solution.


    Ray

  

  On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen 
wrote:
  
  
Dear Sir,
  
  
  Regarding the case57, the voltage of bus 31
is 0.936 p.u which is less than the min. limit
of bus voltage (0.94). Every time I run 'runpf',
the voltage value is 0.936 and it doesn't change
although it is a PQ bus.
  I need your help, please.   
  
  
  
  Regards,
  Mohamed Shaheen.
  
  
  Msc. student at Ain Shams University in Egypt
  Teaching Assistant in Future University in
Egypt

ᐧ
  

  
  

  

  


  

Re: power flow problem

[Mohamed Shaheen]

I need to enforce limits, but I aim to get the optimal solution and best
parameters using another optimization method called 'Tree Seed' and compare
it with 'Genetic Algorithm' after running normal power flow, So I'm not
seeking the optimal solution using Matpower itself.
Can Matpower help to do this?

ᐧ

On Fri, 8 Feb 2019 at 23:53, Ray Zimmerman  wrote:

> The power flow problem solved by runpf does not take into account voltage
> limits. If you need to enforce limits, you can use an appropriately
> constrained OPF.
>
> In this case, it just so happens that the initial voltage specified for
> bus 31 in the case57.m file happens to be the voltage at the power flow
> solution.
>
> Ray
>
>
> On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen 
> wrote:
>
> Dear Sir,
>
> Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less
> than the min. limit of bus voltage (0.94). Every time I run 'runpf', the
> voltage value is 0.936 and it doesn't change although it is a PQ bus.
> I need your help, please.
>
> Regards,
> Mohamed Shaheen.
>
> Msc. student at Ain Shams University in Egypt
> Teaching Assistant in Future University in Egypt
> ᐧ
>
>
>

Re: power flow problem

[Mirish Thakur]

Didn't  understand your question. If I'm correct then you're performing
simple power flow on your case. In this case solver doesn't consider any
restriction/ constraints on problem, means, No branch limits No voltage
limits are applicable . If you want to impose any voltage limits on system
then you have to run optimal power flow. So, instead runpf(case57) , you've
to perform runopf(case57) then you'll see desired output. Please go through
this link might clear your doubt:
*https://www.mail-archive.com/matpower-l@cornell.edu/msg02926.html
*
Thank you.

On Fri, Feb 8, 2019 at 9:54 PM Mohamed Shaheen <
mohamed.shaheen9...@gmail.com> wrote:

> Dear Sir,
>
> Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less
> than the min. limit of bus voltage (0.94). Every time I run 'runpf', the
> voltage value is 0.936 and it doesn't change although it is a PQ bus.
> I need your help, please.
>
> Regards,
> Mohamed Shaheen.
>
> Msc. student at Ain Shams University in Egypt
> Teaching Assistant in Future University in Egypt
> ᐧ
>

Re: power flow problem

[Ray Zimmerman]

The power flow problem solved by runpf does not take into account voltage 
limits. If you need to enforce limits, you can use an appropriately constrained 
OPF.

In this case, it just so happens that the initial voltage specified for bus 31 
in the case57.m file happens to be the voltage at the power flow solution.

Ray


> On Feb 8, 2019, at 2:54 PM, Mohamed Shaheen  
> wrote:
> 
> Dear Sir,
> 
> Regarding the case57, the voltage of bus 31 is 0.936 p.u which is less than 
> the min. limit of bus voltage (0.94). Every time I run 'runpf', the voltage 
> value is 0.936 and it doesn't change although it is a PQ bus.
> I need your help, please.   
> 
> Regards,
> Mohamed Shaheen.
> 
> Msc. student at Ain Shams University in Egypt
> Teaching Assistant in Future University in Egypt
> ᐧ

Re: Power Flow in Matpower

[Ray Zimmerman]

   293 293 
>> 1   0   1   -360360;
>> 30   29  0.0034410.0226660.0194  293 293 293 
>> 1   0   1   -360360;
>> 37   39  0.0040440.0266330.0228  293 293 293 
>> 1   0   1   -360360;
>> 39   40  0.0007130.0015620.1176  293 293 293 
>> 1   0   1   -360360;
>> 18   19  0.0009460.0018470.1644  375 375 375 
>> 1   0   1   -360360;
>> 74   71  0.0025810.0170000.0146  293 293 293 
>> 1   0   1   -360360;
>> 75   74  0.0027900.0183760.0157  293 293 293 
>> 1   0   1   -360360;
>> 69   70  0.0034410.0226660.0194  293 293 293 
>> 1   0   1   -360360;
>> 57   55  0.0019200.0122910.0236  293 293 293 
>> 1   0   1   -360360;
>> 20   19  0.0009090.0017750.1580  375 375 375 
>> 1   0   1   -360360;
>> 21   20  0.0010320.0020150.1793  375 375 375 
>> 1   0   1   -360360;
>> 60   61  0.270.0061330.  375037503750
>> 1.160   1   -360360;
>> 98   0.750.0110370.  200020002000
>> 1.020   1   -360360;
>> 59   58  0.0001500.0214790.  100010001000
>> 1.060   1   -360360;
>> 58   57  0.000.0232800.  100010001000
>> 1.010   1   -360360;
>> 623  0.0001500.0232630.  100010001000
>> 0.980   1   -360360;
>> 88   87  0.0001500.0232630.  100010001000
>> 1.010   1   -360360;
>> 43   44  0.0001500.0222610.  100010001000
>> 0.9 0   1   -360360;
>> 232  0.0001500.0213820.  100010001000
>> 0.950   1   -360360;
>> 428  0.0001500.0213820.  100010001000
>> 0.9 0   1   -360360;
>> 12   13  0.0001500.0238550.  100010001000
>> 1   0   1   -360360;
>> 45   46  0.0001500.0222610.  100010001000
>> 0.990   1   -360360;
>> 62   63  0.0001500.0232800.  100010001000
>> 1.020   1   -360360;
>> 79   78  0.0001500.0232800.  100010001000
>> 1.1 0   1   -360360;
>> 871  0.0001500.0232800.  100010001000
>> 1   0   1   -360360;
>> 41   37  0.0002520.0221700.  630 630 630 
>> 1   0   1   -360360;
>> ];
>> 
>> 
>> 
>> and i got some buses relatively far from the real values
>> 
>> the real values of the voltage are attached 
>> 
>> On 21 March 2018 at 17:33, Carlos E Murillo-Sanchez 
>> <ce.murillosanc...@gmail.com <mailto:ce.murillosanc...@gmail.com>> wrote:
>> The Ybus matrix computed from the data in your file has NaN's and Inf's 
>> because branch # 69 from bus 16 to bus 17 has zero series impedance.  You 
>> must collapse buses 16 and 17 into a single bus before applying any 
>> algorithm to the system because the electrical "distance" between these two 
>> buses is zero.
>> 
>> Carlos.
>> 
>> Mohammed Alhajri wrote:
>>> i got
>>> 
>>> 
>>> 
>>> 19980   NaN
>>> 19981   NaN
>>> 19982   NaN
>>> 19983   NaN
>>> 19984   NaN
>>> 19985   NaN
>>> 19986   NaN
>>> 19987   NaN
>>> 19988   NaN
>>> 19989   NaN
>>> 19990   NaN
>>> 19991   NaN
>>> 19992   NaN
>>> 19993   NaN
>>> 19994   NaN
>>> 19995   NaN
>>> 19996   NaN
>>> 19997   NaN
>>> 19998   NaN
>>

Re: Power Flow in Matpower

[Mohammed Alhajri]

se from the Hadi Sadat code?
>>>
>>> And if you have any questions about the MATPOWER case format or MATPOWER
>>> power flow options, feel free to ask.
>>>
>>> Ray
>>>
>>>
>>>
>>> On Mar 20, 2018, at 11:28 AM, Mohammed Alhajri <u106...@gmail.com>
>>> wrote:
>>>
>>> Ok, i have attached the case information in format of Hadi Saadat code,
>>> can you please try it in MATPOWER?
>>>
>>> because we have spent more than three weeks checking the format, but
>>> still dose not converge...
>>>
>>> Regards,,,
>>>
>>> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:
>>>
>>>> It’s possible that the modeling is not identical or that there is some
>>>> error in your conversion to MATPOWER format. You can check by talking the
>>>> solved case from your other software, converting that solved case to
>>>> MATPOWER and then trying the MATPOWER power flow. It should converge in a
>>>> single iteration. If it does not, then you know that there is either a
>>>> mistake somewhere or a difference in modeling.
>>>>
>>>>Ray
>>>>
>>>>
>>>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri < <u106...@gmail.com>
>>>> u106...@gmail.com> wrote:
>>>>
>>>> i tried that but unfortunately not work
>>>>
>>>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <
>>>> <abhy...@anl.gov>abhy...@anl.gov>:
>>>>
>>>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Shri
>>>>>
>>>>> Ph: (630) 252 0219 <%28630%29%20252-0219>
>>>>>
>>>>> www.mcs.anl.gov/~abhyshr <http://www.mcs.anl.gov/%7Eabhyshr>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
>>>>> Mohammed Alhajri < <u106...@gmail.com>u106...@gmail.com>
>>>>> *Reply-To: *MATPOWER discussion forum < <matpowe...@list.cornell.edu>
>>>>> matpowe...@list.cornell.edu>
>>>>> * Date: Friday, March 16, 2018 at 11:26 AM *
>>>>> * To: MATPOWER discussion forum <
>>>>> <matpowe...@list.cornell.edu>matpowe...@list.cornell.edu
>>>>> <matpowe...@list.cornell.edu>> *
>>>>> * Subject: Re: Power Flow in Matpower *
>>>>>
>>>>>
>>>>>
>>>>> any answer to this question?
>>>>>
>>>>>
>>>>> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" < <u106...@gmail.com>
>>>>> u106...@gmail.com>:
>>>>>
>>>>> Hello All,
>>>>>
>>>>>
>>>>> I did the power flow for a 89-bus network and it converges using Hadi
>>>>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
>>>>> Gauss-Seidel Method.
>>>>>
>>>>>
>>>>> But when I did the power flow using matpower it does not converge! I
>>>>> tried to increase the maximum iteration, I put it 10, and still did 
>>>>> not
>>>>> cnvarge!
>>>>>
>>>>>
>>>>> I have attached the data according to Hadi Sadat Code, can any one try
>>>>> to do the power flow using matpower?
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 
>
>
>

Re: Power Flow in Matpower

[Ray Zimmerman]

60;
> 2 32  0.0001500.0213820.  100010001000
> 0.950   1   -360360;
> 4 28  0.0001500.0213820.  100010001000
> 0.9 0   1   -360360;
> 1213  0.0001500.0238550.  100010001000
> 1   0   1   -360360;
> 4546  0.0001500.0222610.  100010001000
> 0.990   1   -360360;
> 6263  0.0001500.0232800.  100010001000
> 1.020   1   -360360;
> 7978  0.0001500.0232800.  100010001000
> 1.1 0   1   -360360;
> 8 71  0.0001500.0232800.  100010001000
> 1   0   1   -360360;
> 4137  0.0002520.0221700.  630 630 630 
> 1   0   1   -360360;
> ];
> 
> 
> 
> and i got some buses relatively far from the real values
> 
> the real values of the voltage are attached 
> 
> On 21 March 2018 at 17:33, Carlos E Murillo-Sanchez 
> <ce.murillosanc...@gmail.com <mailto:ce.murillosanc...@gmail.com>> wrote:
> The Ybus matrix computed from the data in your file has NaN's and Inf's 
> because branch # 69 from bus 16 to bus 17 has zero series impedance.  You 
> must collapse buses 16 and 17 into a single bus before applying any algorithm 
> to the system because the electrical "distance" between these two buses is 
> zero.
> 
> Carlos.
> 
> Mohammed Alhajri wrote:
>> i got
>> 
>> 
>> 
>> 19980   NaN
>> 19981   NaN
>> 19982   NaN
>> 19983   NaN
>> 19984   NaN
>> 19985   NaN
>> 19986   NaN
>> 19987   NaN
>> 19988   NaN
>> 19989   NaN
>> 19990   NaN
>> 19991   NaN
>> 19992   NaN
>> 19993   NaN
>> 19994   NaN
>> 19995   NaN
>> 19996   NaN
>> 19997   NaN
>> 19998   NaN
>> 1   NaN
>> 2   NaN
>> Gauss-Seidel power flow did not converge in 2 iterations.
>> 
>> >>>>>  Did NOT converge (47.99 seconds)  <<<<<
>> 
>> 
>> On 20 March 2018 at 19:44, Ray Zimmerman <r...@cornell.edu 
>> <mailto:r...@cornell.edu>> wrote:
>> Unfortunately, I do not have time to work on this myself. I was just giving 
>> a suggestion for another direction to try if you want to understand the 
>> issue that MATPOWER is having with your case. Could you post the output 
>> (using verbose set to 2) of runpf() when using a MATPOIWER case file that 
>> corresponds to the solved case from the Hadi Sadat code?
>> 
>> And if you have any questions about the MATPOWER case format or MATPOWER 
>> power flow options, feel free to ask.
>> 
>> Ray
>> 
>> 
>> 
>>> On Mar 20, 2018, at 11:28 AM, Mohammed Alhajri <u106...@gmail.com 
>>> <mailto:u106...@gmail.com>> wrote:
>>> 
>>> Ok, i have attached the case information in format of Hadi Saadat code, can 
>>> you please try it in MATPOWER? 
>>> 
>>> because we have spent more than three weeks checking the format, but still 
>>> dose not converge... 
>>> 
>>> Regards,,, 
>>> 
>>> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu 
>>> <mailto:r...@cornell.edu>>:
>>> It’s possible that the modeling is not identical or that there is some 
>>> error in your conversion to MATPOWER format. You can check by talking the 
>>> solved case from your other software, converting that solved case to 
>>> MATPOWER and then trying the MATPOWER power flow. It should converge in a 
>>> single iteration. If it does not, then you know that there is either a 
>>> mistake somewhere or a difference in modeling.
>>> 
>>>Ray
>>> 
>>> 
>>>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri < 
>>>> <mailto:u106...@gmail.com>u106...@gmail.com <mailto:u106...@gmail.com>> 
>>>> wrote:
>>>> 
>>>> i tried that but unfortunately not work 
>>>> 
>>>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." < 
>>>> <mailto:abhy...@anl.gov>abhy...@anl.gov <mailto:abhy...@anl.gov>>:
>>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>>  
>>>> Thanks,
>>>> 
>>>> Shri
>>>> 
>>>> Ph: (630) 252 0219 <tel:%28630%29%20252-0219>
>>>> www.mcs.anl.gov/~abhyshr <http://www.mcs.anl.gov/%7Eabhyshr>
>>>>  
>>>>  
>>>>  
>>>> 
>>>> From: <bounce-122387760-73493...@list.cornell.edu 
>>>> <mailto:bounce-122387760-73493...@list.cornell.edu>> on behalf of Mohammed 
>>>> Alhajri < <mailto:u106...@gmail.com>u106...@gmail.com 
>>>> <mailto:u106...@gmail.com>>
>>>> Reply-To: MATPOWER discussion forum < 
>>>> <mailto:matpowe...@list.cornell.edu>matpowe...@list.cornell.edu 
>>>> <mailto:matpowe...@list.cornell.edu>>
>>>> Date: Friday, March 16, 2018 at 11:26 AM
>>>> To: MATPOWER discussion forum < 
>>>> <mailto:matpowe...@list.cornell.edu>matpowe...@list.cornell.edu 
>>>> <mailto:matpowe...@list.cornell.edu>>
>>>> Subject: Re: Power Flow in Matpower
>>>> 
>>>>  
>>>> any answer to this question?
>>>> 
>>>>  
>>>> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" < 
>>>> <mailto:u106...@gmail.com>u106...@gmail.com <mailto:u106...@gmail.com>>:
>>>> 
>>>> Hello All,
>>>> 
>>>>  
>>>> I did the power flow for a 89-bus network and it converges using Hadi 
>>>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is 
>>>> Gauss-Seidel Method.
>>>> 
>>>>  
>>>> But when I did the power flow using matpower it does not converge! I tried 
>>>> to increase the maximum iteration, I put it 10, and still did not 
>>>> cnvarge!
>>>> 
>>>>  
>>>> I have attached the data according to Hadi Sadat Code, can any one try to 
>>>> do the power flow using matpower?
>>>> 
>>>>  
>>> 
>> 
>> 
> 
> 
> 

Re: Power Flow in Matpower

[Mohammed Alhajri]

 0.00 0.023280 0. 1000 1000 1000 1.01 0 1 -360 360;
6 23 0.000150 0.023263 0. 1000 1000 1000 0.98 0 1 -360 360;
88 87 0.000150 0.023263 0. 1000 1000 1000 1.01 0 1 -360 360;
43 44 0.000150 0.022261 0. 1000 1000 1000 0.9 0 1 -360 360;
2 32 0.000150 0.021382 0. 1000 1000 1000 0.95 0 1 -360 360;
4 28 0.000150 0.021382 0. 1000 1000 1000 0.9 0 1 -360 360;
12 13 0.000150 0.023855 0. 1000 1000 1000 1 0 1 -360 360;
45 46 0.000150 0.022261 0. 1000 1000 1000 0.99 0 1 -360 360;
62 63 0.000150 0.023280 0. 1000 1000 1000 1.02 0 1 -360 360;
79 78 0.000150 0.023280 0. 1000 1000 1000 1.1 0 1 -360 360;
8 71 0.000150 0.023280 0. 1000 1000 1000 1 0 1 -360 360;
41 37 0.000252 0.022170 0. 630 630 630 1 0 1 -360 360;
];



and i got some buses relatively far from the real values

the real values of the voltage are attached

On 21 March 2018 at 17:33, Carlos E Murillo-Sanchez <
ce.murillosanc...@gmail.com> wrote:

> The Ybus matrix computed from the data in your file has NaN's and Inf's
> because branch # 69 from bus 16 to bus 17 has zero series impedance.  You
> must collapse buses 16 and 17 into a single bus before applying any
> algorithm to the system because the electrical "distance" between these two
> buses is zero.
>
> Carlos.
>
> Mohammed Alhajri wrote:
>
> i got
>
> 
>
> 19980   NaN
> 19981   NaN
> 19982   NaN
> 19983   NaN
> 19984   NaN
> 19985   NaN
> 19986   NaN
> 19987   NaN
> 19988   NaN
> 19989   NaN
> 19990   NaN
> 19991   NaN
> 19992   NaN
> 19993   NaN
> 19994   NaN
> 19995   NaN
> 19996   NaN
> 19997   NaN
> 19998   NaN
> 1   NaN
> 2   NaN
> Gauss-Seidel power flow did not converge in 2 iterations.
>
> >>>>>  Did NOT converge (47.99 seconds)  <<<<<
>
>
> On 20 March 2018 at 19:44, Ray Zimmerman <r...@cornell.edu> wrote:
>
>> Unfortunately, I do not have time to work on this myself. I was just
>> giving a suggestion for another direction to try if you want to understand
>> the issue that MATPOWER is having with your case. Could you post the output
>> (using verbose set to 2) of runpf() when using a MATPOIWER case file
>> that corresponds to the solved case from the Hadi Sadat code?
>>
>> And if you have any questions about the MATPOWER case format or MATPOWER
>> power flow options, feel free to ask.
>>
>> Ray
>>
>>
>>
>> On Mar 20, 2018, at 11:28 AM, Mohammed Alhajri <u106...@gmail.com> wrote:
>>
>> Ok, i have attached the case information in format of Hadi Saadat code,
>> can you please try it in MATPOWER?
>>
>> because we have spent more than three weeks checking the format, but
>> still dose not converge...
>>
>> Regards,,,
>>
>> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:
>>
>>> It’s possible that the modeling is not identical or that there is some
>>> error in your conversion to MATPOWER format. You can check by talking the
>>> solved case from your other software, converting that solved case to
>>> MATPOWER and then trying the MATPOWER power flow. It should converge in a
>>> single iteration. If it does not, then you know that there is either a
>>> mistake somewhere or a difference in modeling.
>>>
>>>Ray
>>>
>>>
>>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri < <u106...@gmail.com>
>>> u106...@gmail.com> wrote:
>>>
>>> i tried that but unfortunately not work
>>>
>>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <
>>> <abhy...@anl.gov>abhy...@anl.gov>:
>>>
>>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Shri
>>>>
>>>> Ph: (630) 252 0219 <%28630%29%20252-0219>
>>>>
>>>> www.mcs.anl.gov/~abhyshr <http://www.mcs.anl.gov/%7Eabhyshr>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
>>>> Mohammed Alhajri < <u106...@gmail.com>u106...@gmail.com>
>>>> *Reply-To: *MATPOWER discu

Re: Power Flow in Matpower

[Carlos E Murillo-Sanchez]

;u106...@gmail.com>
  wrote:


  i tried
that but unfortunately
not work 
  



  بتاريخ
٢٠١٨/٠٣/١٦ ٨:٣٠ م،
كتب "Abhyankar,
Shrirang G." <abhy...@anl.gov>:
  

  
See FAQ #5
 

  Thanks,
  Shri
  Ph: (630) 252 0219
  www.mcs.anl.gov/~abhyshr
   

 
 

  
  
  From:
  <bounce-122387760-73493617@list.cornell.edu>
  on behalf of
  Mohammed
  Alhajri <u106...@gmail.com>
  
  Reply-To:
  MATPOWER
  discussion
  forum <matpowe...@list.cornell.edu>
  
  Date:
  Friday,
  March 16, 2018
  at 11:26 AM
  
  
  To:
  MATPOWER
  discussion
  forum <matpowe...@list.cornell.edu>
  
  
          Subject:
  Re: Power
  Flow in
  Matpower
  
  
  


   


  any answer to this question?


   
  
  بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب
  "Mohammed
  Alhajri" <u106...@gmail.com>:
   

Re: Power Flow in Matpower

[Jose Luis Marín]

Hello Mohammed,

The problem is in the *branch joining buses 16 and 17* (line 191 in the
file).  This branch had zero R and zero X.  Just edit the value of X to
something reasonable (I used 0.001), and the case solves just fine, in 4
iterations.

-- 
Jose L. Marin
Grupo AIA



2018-03-21 3:51 GMT+01:00 Mohammed Alhajri <u106...@gmail.com>:

> i got
>
> 
>
> 19980   NaN
> 19981   NaN
> 19982   NaN
> 19983   NaN
> 19984   NaN
> 19985   NaN
> 19986   NaN
> 19987   NaN
> 19988   NaN
> 19989   NaN
> 19990   NaN
> 19991   NaN
> 19992   NaN
> 19993   NaN
> 19994   NaN
> 19995   NaN
> 19996   NaN
> 19997   NaN
> 19998   NaN
> 1   NaN
> 2   NaN
> Gauss-Seidel power flow did not converge in 2 iterations.
>
> >>>>>  Did NOT converge (47.99 seconds)  <<<<<
>
>
> On 20 March 2018 at 19:44, Ray Zimmerman <r...@cornell.edu> wrote:
>
>> Unfortunately, I do not have time to work on this myself. I was just
>> giving a suggestion for another direction to try if you want to understand
>> the issue that MATPOWER is having with your case. Could you post the output
>> (using verbose set to 2) of runpf() when using a MATPOIWER case file
>> that corresponds to the solved case from the Hadi Sadat code?
>>
>> And if you have any questions about the MATPOWER case format or MATPOWER
>> power flow options, feel free to ask.
>>
>> Ray
>>
>>
>>
>> On Mar 20, 2018, at 11:28 AM, Mohammed Alhajri <u106...@gmail.com> wrote:
>>
>> Ok, i have attached the case information in format of Hadi Saadat code,
>> can you please try it in MATPOWER?
>>
>> because we have spent more than three weeks checking the format, but
>> still dose not converge...
>>
>> Regards,,,
>>
>> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:
>>
>>> It’s possible that the modeling is not identical or that there is some
>>> error in your conversion to MATPOWER format. You can check by talking the
>>> solved case from your other software, converting that solved case to
>>> MATPOWER and then trying the MATPOWER power flow. It should converge in a
>>> single iteration. If it does not, then you know that there is either a
>>> mistake somewhere or a difference in modeling.
>>>
>>>Ray
>>>
>>>
>>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri <u106...@gmail.com>
>>> wrote:
>>>
>>> i tried that but unfortunately not work
>>>
>>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <abhy...@anl.gov
>>> >:
>>>
>>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Shri
>>>>
>>>> Ph: (630) 252 0219 <(630)%20252-0219>
>>>>
>>>> www.mcs.anl.gov/~abhyshr
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
>>>> Mohammed Alhajri <u106...@gmail.com>
>>>> *Reply-To: *MATPOWER discussion forum <matpowe...@list.cornell.edu>
>>>> *Date: Friday, March 16, 2018 at 11:26 AM*
>>>> *To: MATPOWER discussion forum <matpowe...@list.cornell.edu
>>>> <matpowe...@list.cornell.edu>>*
>>>> *Subject: Re: Power Flow in Matpower*
>>>>
>>>>
>>>>
>>>> any answer to this question?
>>>>
>>>>
>>>>
>>>> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" <u106...@gmail.com>:
>>>>
>>>> Hello All,
>>>>
>>>>
>>>>
>>>> I did the power flow for a 89-bus network and it converges using Hadi
>>>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
>>>> Gauss-Seidel Method.
>>>>
>>>>
>>>>
>>>> But when I did the power flow using matpower it does not converge! I
>>>> tried to increase the maximum iteration, I put it 10, and still did not
>>>> cnvarge!
>>>>
>>>>
>>>>
>>>> I have attached the data according to Hadi Sadat Code, can any one try
>>>> to do the power flow using matpower?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: Power Flow in Matpower

[Mohammed Alhajri]

i got



19980   NaN
19981   NaN
19982   NaN
19983   NaN
19984   NaN
19985   NaN
19986   NaN
19987   NaN
19988   NaN
19989   NaN
19990   NaN
19991   NaN
19992   NaN
19993   NaN
19994   NaN
19995   NaN
19996   NaN
19997   NaN
19998   NaN
1   NaN
2   NaN
Gauss-Seidel power flow did not converge in 2 iterations.

>>>>>  Did NOT converge (47.99 seconds)  <<<<<


On 20 March 2018 at 19:44, Ray Zimmerman <r...@cornell.edu> wrote:

> Unfortunately, I do not have time to work on this myself. I was just
> giving a suggestion for another direction to try if you want to understand
> the issue that MATPOWER is having with your case. Could you post the output
> (using verbose set to 2) of runpf() when using a MATPOIWER case file that
> corresponds to the solved case from the Hadi Sadat code?
>
> And if you have any questions about the MATPOWER case format or MATPOWER
> power flow options, feel free to ask.
>
> Ray
>
>
>
> On Mar 20, 2018, at 11:28 AM, Mohammed Alhajri <u106...@gmail.com> wrote:
>
> Ok, i have attached the case information in format of Hadi Saadat code,
> can you please try it in MATPOWER?
>
> because we have spent more than three weeks checking the format, but still
> dose not converge...
>
> Regards,,,
>
> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:
>
>> It’s possible that the modeling is not identical or that there is some
>> error in your conversion to MATPOWER format. You can check by talking the
>> solved case from your other software, converting that solved case to
>> MATPOWER and then trying the MATPOWER power flow. It should converge in a
>> single iteration. If it does not, then you know that there is either a
>> mistake somewhere or a difference in modeling.
>>
>>Ray
>>
>>
>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri <u106...@gmail.com> wrote:
>>
>> i tried that but unfortunately not work
>>
>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <abhy...@anl.gov>:
>>
>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Shri
>>>
>>> Ph: (630) 252 0219 <(630)%20252-0219>
>>>
>>> www.mcs.anl.gov/~abhyshr
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
>>> Mohammed Alhajri <u106...@gmail.com>
>>> *Reply-To: *MATPOWER discussion forum <matpowe...@list.cornell.edu>
>>> *Date: Friday, March 16, 2018 at 11:26 AM*
>>> *To: MATPOWER discussion forum <matpowe...@list.cornell.edu
>>> <matpowe...@list.cornell.edu>>*
>>> *Subject: Re: Power Flow in Matpower*
>>>
>>>
>>>
>>> any answer to this question?
>>>
>>>
>>>
>>> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" <u106...@gmail.com>:
>>>
>>> Hello All,
>>>
>>>
>>>
>>> I did the power flow for a 89-bus network and it converges using Hadi
>>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
>>> Gauss-Seidel Method.
>>>
>>>
>>>
>>> But when I did the power flow using matpower it does not converge! I
>>> tried to increase the maximum iteration, I put it 10, and still did not
>>> cnvarge!
>>>
>>>
>>>
>>> I have attached the data according to Hadi Sadat Code, can any one try
>>> to do the power flow using matpower?
>>>
>>>
>>>
>>>
>>
>

Re: Power Flow in Matpower

[Mohammed Alhajri]

   196.0   528.4
> 92.0
>   off   -   -   -
> -   -
>   fixed  6416.2  5599.8   196.0   528.4
> 92.0
>   dispatchable  -   -   -
> -   -
> on  -   -   -
> -   -
> off -   -   -
> -   -
>   reactive (MVAr)
> dispatched   2125.7  1855.664.4   173.7
> 31.9
>   fixed  2125.7  1855.664.4   173.7
> 31.9
>   dispatchable  -   -   -
> -   -
> curtailed   -   -   -
> -   -
> nominal  2125.7  1855.664.4   173.7
> 31.9
>   on 2125.7  1855.664.4   173.7
> 31.9
>   off   -   -   -
> -   -
>   fixed  2125.7  1855.664.4   173.7
> 31.9
>   dispatchable  -   -   -
> -   -
> on  -   -   -
> -   -
> off -   -   -
> -   -
>
> Generation
>   active (MW)
> dispatched   6621.8  6234.6   387.3
> -   -
> max capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
> min capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
>   reactive (MVAr)
> dispatched   2762.6  2601.0   161.7
> -   -
> max capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
> min capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
>
> Shunt Injections
> active (MW) -   -   -
> -   -
> reactive (MVAr)  1934.0  1894.0 -   -
> 40.0
>
> Branch Losses
> active (MW) -   -   -
> -   -
> reactive (MVAr) -   -   -
> -   -
>
> DC line
>   export (MW)
> dispatch-   -   -
> -   -
> max capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
> min capacity-   -   -
> -   -
>   on-   -   -
> -   -
>   off   -   -   -
> -   -
>
> Reference Buses
>   num of ref buses  1   1   0
> 0   0
>   ref bus numbers  27  27
>
>
> Is this what the data is supposed to represent?
>
> Carlos.
>
> Mohammed Alhajri wrote:
>
> Ok, i have attached the case information in format of Hadi Saadat code,
> can you please try it in MATPOWER?
>
> because we have spent more than three weeks checking the format, but still
> dose not converge...
>
> Regards,,,
>
> بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:
>
>> It’s possible that the modeling is not identical or that there is some
>> error in your conversion to MATPOWER format. You can check by talking the
>> solved case from your other software, converting that solved case to
>> MATPOWER and then trying the MATPOWER power flow. It should converge in a
>> single iteration. If it does not, then you know that there is either a
>> mistake somewhere or a difference in modeling.
>>
>>Ray
>>
>>
>> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri <u106...@gmail.com> wrote:
>>
>> i tried that but unfortunately not work
>>
>> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <
>> <abhy...@anl.gov>abhy...@anl.gov>:
>>
>>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Shri
>>>
>>> Ph: (630) 2

Re: Power Flow in Matpower

[Mohammed Alhajri]

this is the *.m file of the case

On 21 March 2018 at 02:01, André Silva  wrote:

> Hi Mohammed,
>
>
> It is easier for anyone here to make an objective analysis of your case,
> if you provide the network refered in Hadi Saadat alterady converted into
> the MatPower version 2 network case format. You just have to adapt your
> excel network information sheets into an *.m file
>
>
> Typically any Power Flow execution for any given network case takes less
> than a dozen or so iterations to converge. This is verifiable not only for
> small networks, but also for networks with thousands of nodes.
>
>
> Best regards,
>
> André
>
> 2018-02-25 15:18 GMT+00:00 Mohammed Alhajri :
>
>> Hello All,
>>
>> I did the power flow for a 89-bus network and it converges using Hadi
>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
>> Gauss-Seidel Method.
>>
>>
>>
>> But when I did the power flow using matpower it does not converge! I
>> tried to increase the maximum iteration, I put it 10, and still did not
>> cnvarge!
>>
>>
>>
>> I have attached the data according to Hadi Sadat Code, can any one try to
>> do the power flow using matpower?
>>
>>
>


OETC_PF.m
Description: Binary data

Re: Power Flow in Matpower

[Carlos E Murillo-Sanchez]

h 16, 2018 at
11:26 AM


  To:
MATPOWER discussion forum
<matpowe...@list.cornell.edu>


          Subject:
Re: Power Flow in Matpower



   


  any
answer to this question?


   
  
بتاريخ
  ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed
  Alhajri" <u106...@gmail.com>:

  
Hello
  All, 

   


  I
  did the power flow for a
  89-bus network and it
  converges using Hadi Sadat
  code after 17080
  iterations. The accuracy
  was 1e-8 and the method is
  Gauss-Seidel Method.
   
  But
  when I did the power flow
  using matpower it does not
  converge! I tried to
  increase the maximum
  iteration, I put it
  10, and still did not
  cnvarge!
   
  I
  have attached the data
  according to Hadi Sadat
  Code, can any one try to
  do the power flow using
  matpower?
   

  

  

  

  

  

  


  

  

  


  

Re: Power Flow in Matpower

[André Silva]

Hi Mohammed,


It is easier for anyone here to make an objective analysis of your case, if
you provide the network refered in Hadi Saadat alterady converted into the
MatPower version 2 network case format. You just have to adapt your excel
network information sheets into an *.m file


Typically any Power Flow execution for any given network case takes less
than a dozen or so iterations to converge. This is verifiable not only for
small networks, but also for networks with thousands of nodes.


Best regards,

André

2018-02-25 15:18 GMT+00:00 Mohammed Alhajri :

> Hello All,
>
> I did the power flow for a 89-bus network and it converges using Hadi
> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
> Gauss-Seidel Method.
>
>
>
> But when I did the power flow using matpower it does not converge! I tried
> to increase the maximum iteration, I put it 10, and still did not
> cnvarge!
>
>
>
> I have attached the data according to Hadi Sadat Code, can any one try to
> do the power flow using matpower?
>
>

Re: Power Flow in Matpower

[Mohammed Alhajri]

Ok, i have attached the case information in format of Hadi Saadat code, can
you please try it in MATPOWER?

because we have spent more than three weeks checking the format, but still
dose not converge...

Regards,,,

بتاريخ ٢٠١٨/٠٣/٢٠ ٦:٢٦ م، كتب "Ray Zimmerman" <r...@cornell.edu>:

> It’s possible that the modeling is not identical or that there is some
> error in your conversion to MATPOWER format. You can check by talking the
> solved case from your other software, converting that solved case to
> MATPOWER and then trying the MATPOWER power flow. It should converge in a
> single iteration. If it does not, then you know that there is either a
> mistake somewhere or a difference in modeling.
>
>Ray
>
>
> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri <u106...@gmail.com> wrote:
>
> i tried that but unfortunately not work
>
> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <abhy...@anl.gov>:
>
>> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>>
>>
>>
>> Thanks,
>>
>> Shri
>>
>> Ph: (630) 252 0219 <(630)%20252-0219>
>>
>> www.mcs.anl.gov/~abhyshr
>>
>>
>>
>>
>>
>>
>>
>> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
>> Mohammed Alhajri <u106...@gmail.com>
>> *Reply-To: *MATPOWER discussion forum <matpowe...@list.cornell.edu>
>> *Date: Friday, March 16, 2018 at 11:26 AM*
>> *To: MATPOWER discussion forum <matpowe...@list.cornell.edu
>> <matpowe...@list.cornell.edu>>*
>> *Subject: Re: Power Flow in Matpower*
>>
>>
>>
>> any answer to this question?
>>
>>
>>
>> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" <u106...@gmail.com>:
>>
>> Hello All,
>>
>>
>>
>> I did the power flow for a 89-bus network and it converges using Hadi
>> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
>> Gauss-Seidel Method.
>>
>>
>>
>> But when I did the power flow using matpower it does not converge! I
>> tried to increase the maximum iteration, I put it 10, and still did not
>> cnvarge!
>>
>>
>>
>> I have attached the data according to Hadi Sadat Code, can any one try to
>> do the power flow using matpower?
>>
>>
>>
>>
>

Re: Power Flow in Matpower

[Ray Zimmerman]

It’s possible that the modeling is not identical or that there is some error in 
your conversion to MATPOWER format. You can check by talking the solved case 
from your other software, converting that solved case to MATPOWER and then 
trying the MATPOWER power flow. It should converge in a single iteration. If it 
does not, then you know that there is either a mistake somewhere or a 
difference in modeling.

   Ray


> On Mar 16, 2018, at 12:42 PM, Mohammed Alhajri <u106...@gmail.com> wrote:
> 
> i tried that but unfortunately not work 
> 
> بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <abhy...@anl.gov 
> <mailto:abhy...@anl.gov>>:
> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>  
> 
> Thanks,
> 
> Shri
> 
> Ph: (630) 252 0219 <tel:(630)%20252-0219>
> www.mcs.anl.gov/~abhyshr <http://www.mcs.anl.gov/~abhyshr>
>  
> 
>  
> 
>  
> 
> From: <bounce-122387760-73493...@list.cornell.edu 
> <mailto:bounce-122387760-73493...@list.cornell.edu>> on behalf of Mohammed 
> Alhajri <u106...@gmail.com <mailto:u106...@gmail.com>>
> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu 
> <mailto:matpowe...@list.cornell.edu>>
> Date: Friday, March 16, 2018 at 11:26 AM
> To: MATPOWER discussion forum <matpowe...@list.cornell.edu 
> <mailto:matpowe...@list.cornell.edu>>
> Subject: Re: Power Flow in Matpower
> 
>  
> 
> any answer to this question?
> 
>  
> 
> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" <u106...@gmail.com 
> <mailto:u106...@gmail.com>>:
> 
> Hello All,
> 
>  
> 
> I did the power flow for a 89-bus network and it converges using Hadi Sadat 
> code after 17080 iterations. The accuracy was 1e-8 and the method is 
> Gauss-Seidel Method.
> 
>  
> 
> But when I did the power flow using matpower it does not converge! I tried to 
> increase the maximum iteration, I put it 10, and still did not cnvarge!
> 
>  
> 
> I have attached the data according to Hadi Sadat Code, can any one try to do 
> the power flow using matpower?
> 
>  
> 

Re: Power Flow in Matpower

[Mohammed Alhajri]

i tried that but unfortunately not work

بتاريخ ٢٠١٨/٠٣/١٦ ٨:٣٠ م، كتب "Abhyankar, Shrirang G." <abhy...@anl.gov>:

> See FAQ #5 <http://www.pserc.cornell.edu/matpower/#pfconvergence>
>
>
>
> Thanks,
>
> Shri
>
> Ph: (630) 252 0219 <(630)%20252-0219>
>
> www.mcs.anl.gov/~abhyshr
>
>
>
>
>
>
>
> *From: *<bounce-122387760-73493...@list.cornell.edu> on behalf of
> Mohammed Alhajri <u106...@gmail.com>
> *Reply-To: *MATPOWER discussion forum <matpowe...@list.cornell.edu>
> *Date: *Friday, March 16, 2018 at 11:26 AM
> *To: *MATPOWER discussion forum <matpowe...@list.cornell.edu>
> *Subject: *Re: Power Flow in Matpower
>
>
>
> any answer to this question?
>
>
>
> بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" <u106...@gmail.com>:
>
> Hello All,
>
>
>
> I did the power flow for a 89-bus network and it converges using Hadi
> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
> Gauss-Seidel Method.
>
>
>
> But when I did the power flow using matpower it does not converge! I tried
> to increase the maximum iteration, I put it 10, and still did not
> cnvarge!
>
>
>
> I have attached the data according to Hadi Sadat Code, can any one try to
> do the power flow using matpower?
>
>
>
>

Re: Power Flow in Matpower

[Abhyankar, Shrirang G.]

See FAQ #5<http://www.pserc.cornell.edu/matpower/#pfconvergence>

Thanks,
Shri
Ph: (630) 252 0219
www.mcs.anl.gov/~abhyshr<http://www.mcs.anl.gov/~abhyshr>



From: <bounce-122387760-73493...@list.cornell.edu> on behalf of Mohammed 
Alhajri <u106...@gmail.com>
Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
Date: Friday, March 16, 2018 at 11:26 AM
To: MATPOWER discussion forum <matpowe...@list.cornell.edu>
Subject: Re: Power Flow in Matpower

any answer to this question?

بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" 
<u106...@gmail.com<mailto:u106...@gmail.com>>:
Hello All,

I did the power flow for a 89-bus network and it converges using Hadi Sadat 
code after 17080 iterations. The accuracy was 1e-8 and the method is 
Gauss-Seidel Method.

But when I did the power flow using matpower it does not converge! I tried to 
increase the maximum iteration, I put it 10, and still did not cnvarge!

I have attached the data according to Hadi Sadat Code, can any one try to do 
the power flow using matpower?

Re: Power Flow in Matpower

[Mohammed Alhajri]

any answer to this question?

بتاريخ ٢٠١٨/٠٢/٢٥ ٧:١٨ م، كتب "Mohammed Alhajri" :

> Hello All,
>
> I did the power flow for a 89-bus network and it converges using Hadi
> Sadat code after 17080 iterations. The accuracy was 1e-8 and the method is
> Gauss-Seidel Method.
>
>
>
> But when I did the power flow using matpower it does not converge! I tried
> to increase the maximum iteration, I put it 10, and still did not
> cnvarge!
>
>
>
> I have attached the data according to Hadi Sadat Code, can any one try to
> do the power flow using matpower?
>
>

Re: Power Flow does not converge

[Ray Zimmerman]

Do you have a small (the smaller the better) example that exhibits this 
problem? It’s possible that convergence requires automatically updating the 
settings of other controls (like other transformer taps or something). 

Thanks,

   Ray


> On Aug 9, 2017, at 7:06 PM, Chenxi Lin  wrote:
> 
> Hello,
>  
> I wonder why non-zero phase angle in transformers connecting PQ buses usually 
> cause power flow not converge. However, if the transformer is connected to a 
> PV bus then PF is converged. For the same case, PSS/E or PowerWorld do not 
> have this issue.
>  
> Thanks in advance,
> Chenxi  

Re: Power Flow for Radial Test Systems with several Feeders

[Andrey Vieira]

Dear Mr. Todorovski, thanks for the answer!



De: bounce-121631454-77188...@list.cornell.edu 
<bounce-121631454-77188...@list.cornell.edu> em nome de Mirko Todorovski 
<mi...@feit.ukim.edu.mk>
Enviado: quinta-feira, 29 de junho de 2017 21:10
Para: MATPOWER discussion forum; MATPOWER-L@cornell.edu
Assunto: Re: Power Flow for Radial Test Systems with several Feeders


Case B can't be solved with PQSUM, ISUM or YSUM since there are three slack 
buses. There must be only one slack (supply) bus for the distribution network.


Case A can be solved but you should put branches 1-2 and 1-3. Their parameters 
may all be zero (r, x and b). However, bear in mind the zero-impedance branches 
are problematic for the Netwon method.


Finally, do you include tie branches 5-11, 10-14 and 7-16? If yes, the network 
consists loops and can't be solved with the current version of PQSUM, ISUM or 
YSUM.


Best regards,

Mirko

On 06/29/2017 03:47 PM, Andrey Vieira wrote:

Hi All. With regard to the use of load flow for radial networks, I would
 like to know if there is for distribution systems with several separately
 represented radial feeders. That is, each one With their respective sources
 (substations).
For example, note the case 16 buses below

[cid:part1.1D613F18.D13FF2F7@feit.ukim.edu.mk]


This case can be represented in MATPOWER in two different ways, as
 below:

A)

%  bus_i type ...


mpc.bus = [ 1  3  ...
2  1  ...
3  1  ...
4  1  ...
5  1  ...
6  1  ...

7  1  ...
8  1  ...
9  1  ...
   10  1  ...
   11  1  ...
   12  1  ...
   13  1  ...
   14  1  ...];



 B)

%  bus_i type ...


mpc.bus = [ 1  3  ...
2  3  ...
3  3  ...
4  1  ...
5  1  ...
6  1  ...

7  1  ...
8  1  ...
9  1  ...
   10  1  ...
   11  1  ...
   12  1  ...
   13  1  ...
   14  1  ...
   15  1  ...
   16  1  ...];


When carrying out the load flow for the two cases (A and B),
success was obtained for the two cases by Newton's method.
However, for the PSUM, ISUM, and YSUM methods, none
of them were successful.
Can anyone tell me if there is the possibility of running the load flow
 for distribution systems Radials that use the representation of a
 substation for each feeder?

Re: Power Flow for Radial Test Systems with several Feeders

[Mirko Todorovski]

Case B can't be solved with PQSUM, ISUM or YSUM since there are three 
slack buses. There must be only one slack (supply) bus for the 
distribution network.



Case A can be solved but you should put branches 1-2 and 1-3. Their 
parameters may all be zero (r, x and b). However, bear in mind the 
zero-impedance branches are problematic for the Netwon method.



Finally, do you include tie branches 5-11, 10-14 and 7-16? If yes, the 
network consists loops and can't be solved with the current version of 
PQSUM, ISUM or YSUM.



Best regards,

Mirko


On 06/29/2017 03:47 PM, Andrey Vieira wrote:
Hi All. With regard to the use of load flow for radial networks, I 
would like to know if there is for distribution systems with several 
separately represented radial feeders. That is, each one With their 
respective sources (substations). For example, note the case 16 buses 
below This case can be represented in MATPOWER in two different ways, 
as below: A)


%bus_itype...

mpc.bus = [ 13 ... 2   1 ... 3 1 ...41 ...5 1...6 1...

7 1...

81...9 1... 10 1... 11 1... 12 1... 13 1... 14 1 ...];

B)

%bus_itype...

mpc.bus = [ 13 ... 2   3 ... 3 3 ...41 ...5 1...6 1...

7 1...

81...9 1... 10 1... 11 1... 12 1... 13 1... 14 1 ... 15 1 ... 16 1 
...];When carrying out the load flow for the two cases (A and B), 
success was obtained for the two cases by Newton's method. However, 
for the PSUM, ISUM, and YSUM methods, none of them were successful. 
Can anyone tell me if there is the possibility of running the load 
flow for distribution systems Radials that use the representation of a 
substation for each feeder?

Re: Power flow VM VA, CPF end point

[Elis Nycander]

I see, that's interesting. Thanks!

2017-05-22 10:00 GMT+02:00 Jose Luis Marín :

>
> 1. Yes, VM VA are used both for input and output. Note one subtle point,
> though: in runpf.m (Lines 177--183) the initial seed for the iteration is
> first set to the values [VM VA] provided as input, but for
> voltage-controlled buses (with active generators), the value of VM is
> replaced by the setpoint VG of their respective bus generator(s) (the value
> of VA is preserved). This makes sense because it guarantees that the seed
> will be closer to the solution.
>
> 2. What you see here is to be expected. Basically, what happens is that
> the basins of attraction of low-voltage volutions are usually smaller than
> those of the operating solution. Also, note that there are *many* (for N
> buses, somewhat of the order of 2^N) low voltage solutions, so chances are
> that the iteration will converge to a solution that's different from the
> one you followed by homotopy (CPF). Even homotopy methods can encounter
> this same problem if their step-size is not small enough.
>
>
> Here's some refs on the fractal nature of the problem:
>
> @INPROCEEDINGS{KlumpOverbye00b,
> author={Klump, R.P. and Overbye, T.J.},
> booktitle={Power Engineering Society Summer Meeting},
> title={A new method for finding low-voltage power flow solutions},
> publisher={IEEE},
> year={2000},
> volume={1},
> pages={593--597},
> doi={10.1109/PESS.2000.867653},
> ISSN={}
> }
>
> @INPROCEEDINGS{ThorpNaqavi89,
> author={Thorp, J.S. and Naqavi, S.A.},
> booktitle={Proceedings of the 28th IEEE Conference on Decision and
> Control},
> title={Load flow fractals},
> year={1989},
> volume={2},
> pages={1822--1827},
> doi={10.1109/CDC.1989.70472}
> }
>
> @INPROCEEDINGS{ThorpNaqaviChiang90,
> author={Thorp, J.S. and Naqavi, S.A. and Chiang, H.-D.},
> booktitle={Decision and Control, 1990., Proceedings of the 29th IEEE
> Conference on},
> title={More load flow fractals},
> year={1990},
> month={dec},
> volume={6},
> pages={3028--3030},
> doi={10.1109/CDC.1990.203339}
> }
>
> @ARTICLE{ThorpNaqavi97,
> author={Thorp, J.S. and Naqavi, S.A.},
> journal=IEEE_M_CAP,
> title={Load-flow fractals draw clues to erratic behaviour},
> year={1997},
> month={jan},
> volume={10},
> number={1},
> pages={59--62},
> doi={10.1109/67.560872},
> ISSN={0895-0156}
> }
>
> @INPROCEEDINGS{Mori00,
> author={Mori, H.},
> booktitle={IEEE International Symposium on Circuits and Systems (ISCAS)},
> title={Chaotic behavior of the Newton-Raphson method with the optimal
> multiplier for ill-conditioned power systems},
> year={2000},
> volume={4},
> pages={237--240},
> doi={10.1109/ISCAS.2000.858732}
> }
>
>
> --
> Jose L. Marin
> Grupo AIA
>
>
>
>
> 2017-05-19 11:30 GMT+02:00 Elis Nycander :
>
>> Hi all matpower users!
>>
>> I have two questions:
>>
>> 1. In the bus matrix, the columns VM and VA are used both for the initial
>> guess when solving the power flow, and to store the resulting voltages?
>>
>> 2. When solving a cpf, I get lam_max which corresponds to the nose point,
>> i.e. maximum load/generation increase before "voltage collapse" happens. I
>> can also find the power flow at the nose point just by running an ordinary
>> power flow with flat start and conditions corresponding to the maximum
>> load. However, I have tried to do the same thing for the lower part of the
>> PV curve but failed to reproduce the solutions from the cpf. Basically I
>> thought I could get the lower part of the PV curve by just solving a power
>> flow using initial conditions which are close to the "unstable"/lower
>> solutions from the cpf (instead of a flat start), but I get different
>> solutions.
>>
>> Thanks,
>> Elis
>>
>
>

Re: Power flow VM VA, CPF end point

[Jose Luis Marín]

1. Yes, VM VA are used both for input and output. Note one subtle point,
though: in runpf.m (Lines 177--183) the initial seed for the iteration is
first set to the values [VM VA] provided as input, but for
voltage-controlled buses (with active generators), the value of VM is
replaced by the setpoint VG of their respective bus generator(s) (the value
of VA is preserved). This makes sense because it guarantees that the seed
will be closer to the solution.

2. What you see here is to be expected. Basically, what happens is that the
basins of attraction of low-voltage volutions are usually smaller than
those of the operating solution. Also, note that there are *many* (for N
buses, somewhat of the order of 2^N) low voltage solutions, so chances are
that the iteration will converge to a solution that's different from the
one you followed by homotopy (CPF). Even homotopy methods can encounter
this same problem if their step-size is not small enough.


Here's some refs on the fractal nature of the problem:

@INPROCEEDINGS{KlumpOverbye00b,
author={Klump, R.P. and Overbye, T.J.},
booktitle={Power Engineering Society Summer Meeting},
title={A new method for finding low-voltage power flow solutions},
publisher={IEEE},
year={2000},
volume={1},
pages={593--597},
doi={10.1109/PESS.2000.867653},
ISSN={}
}

@INPROCEEDINGS{ThorpNaqavi89,
author={Thorp, J.S. and Naqavi, S.A.},
booktitle={Proceedings of the 28th IEEE Conference on Decision and Control},
title={Load flow fractals},
year={1989},
volume={2},
pages={1822--1827},
doi={10.1109/CDC.1989.70472}
}

@INPROCEEDINGS{ThorpNaqaviChiang90,
author={Thorp, J.S. and Naqavi, S.A. and Chiang, H.-D.},
booktitle={Decision and Control, 1990., Proceedings of the 29th IEEE
Conference on},
title={More load flow fractals},
year={1990},
month={dec},
volume={6},
pages={3028--3030},
doi={10.1109/CDC.1990.203339}
}

@ARTICLE{ThorpNaqavi97,
author={Thorp, J.S. and Naqavi, S.A.},
journal=IEEE_M_CAP,
title={Load-flow fractals draw clues to erratic behaviour},
year={1997},
month={jan},
volume={10},
number={1},
pages={59--62},
doi={10.1109/67.560872},
ISSN={0895-0156}
}

@INPROCEEDINGS{Mori00,
author={Mori, H.},
booktitle={IEEE International Symposium on Circuits and Systems (ISCAS)},
title={Chaotic behavior of the Newton-Raphson method with the optimal
multiplier for ill-conditioned power systems},
year={2000},
volume={4},
pages={237--240},
doi={10.1109/ISCAS.2000.858732}
}


-- 
Jose L. Marin
Grupo AIA




2017-05-19 11:30 GMT+02:00 Elis Nycander :

> Hi all matpower users!
>
> I have two questions:
>
> 1. In the bus matrix, the columns VM and VA are used both for the initial
> guess when solving the power flow, and to store the resulting voltages?
>
> 2. When solving a cpf, I get lam_max which corresponds to the nose point,
> i.e. maximum load/generation increase before "voltage collapse" happens. I
> can also find the power flow at the nose point just by running an ordinary
> power flow with flat start and conditions corresponding to the maximum
> load. However, I have tried to do the same thing for the lower part of the
> PV curve but failed to reproduce the solutions from the cpf. Basically I
> thought I could get the lower part of the PV curve by just solving a power
> flow using initial conditions which are close to the "unstable"/lower
> solutions from the cpf (instead of a flat start), but I get different
> solutions.
>
> Thanks,
> Elis
>

Re: power flow

[Mounika Vanjarapu]

thank u

On Tue, Apr 12, 2016 at 2:45 PM, Deep Kiran  wrote:

> Dear Mounika,
>
> for example of case5.m
>
> Write the code as:
>
> mpc = loadcase(case5);
> mpc.branch('branch number',6) = 'specify your line limit for the branch of
> your choice';
>
> I hope this helps!
>
> Regards,
> Deep Kiran
>
>
>
> On 12 April 2016 at 14:15, Mounika Vanjarapu 
> wrote:
>
>> can anyone say how to change the power flow limits by writing the code
>> but not by editing the limits.like setting the limits to my wish for some
>> branches
>>
>
>

Re: power flow

[Deep Kiran]

Dear Mounika,

for example of case5.m

Write the code as:

mpc = loadcase(case5);
mpc.branch('branch number',6) = 'specify your line limit for the branch of
your choice';

I hope this helps!

Regards,
Deep Kiran



On 12 April 2016 at 14:15, Mounika Vanjarapu 
wrote:

> can anyone say how to change the power flow limits by writing the code but
> not by editing the limits.like setting the limits to my wish for some
> branches
>

Re: Power flow of a line when using injection model of TCSC

[Ray Zimmerman]

Sorry, but, please restrict discussions here to things that are directly 
related to the use of MATPOWER. Power systems questions that are not specific 
to MATPOWER should be taken to other forums.

Thanks,

 Ray

> On Feb 29, 2016, at 10:22 PM, pham nang van  
> wrote:
> 
> Hi MATPOWER friends
> Please, help me explain the equation (21) given in the article below.
> 
> 
> 

Re: power flow question

[Ray Zimmerman]

Good idea. That should probably be an option though.

Ray

> On Feb 18, 2016, at 11:58 AM, Abhyankar, Shrirang G. <abhy...@anl.gov> wrote:
> 
> I agree. Having the warnings for all generators, voltages, etc. would be 
> helpful for the cases when users are also varying the generation on PV buses. 
> I would even like MATPOWER fixing the active power at PV buses to the max. or 
> min. limit, if the generation exceeds these limits, and informing the users 
> via a warning.
> 
> Shri
> 
> From: Ray Zimmerman <r...@cornell.edu <mailto:r...@cornell.edu>>
> Reply-To: MATPOWER discussion forum <matpowe...@list.cornell.edu 
> <mailto:matpowe...@list.cornell.edu>>
> Date: Thursday, February 18, 2016 at 10:34 AM
> To: MATPOWER discussion forum <matpowe...@list.cornell.edu 
> <mailto:matpowe...@list.cornell.edu>>
> Subject: Re: power flow question
> 
> I agree that checking for exceeded limits and warning about them would be a 
> nice feature to add to the the power flow. I see no reason, though, why it 
> should be limited to the swing bus power injection … why not include all of 
> the other generator, voltage and branch flow limits, all of which can be 
> violated in a converged power flow solution.
> 
> I’ll put it on the “to do” list.
> 
>Ray
> 
> 
>> On Feb 18, 2016, at 8:05 AM, Jovan Ilic <jovan.i...@gmail.com 
>> <mailto:jovan.i...@gmail.com>> wrote:
>> 
>> 
>> Jose,
>> 
>> I did not suggest to turn the swing bus into a PV bus. There should be at 
>> least one swing bus
>> in the system unless you formulate your PF problem as ACOPF problem which 
>> does not need
>> any slack buses. 
>> 
>> I understand what you are saying and you are right. I'd keep the swing bus 
>> as it is just
>> to provide the angle reference (admittance matrix is rarely singular) and 
>> add to Jacobian a
>> constraint on the sum of P and Q flows on the lines connected to the swing 
>> bus.  The sum 
>> of all these lines out flows must be less than the power injection 
>> capability of the swing bus, 
>> both P and Q. If the constraint is violated the power flow does not 
>> converge. The original 
>> poster was concerned with the convergence when there is not enough 
>> generation, so 
>> no convergence would give them a really stern "warning" and leave them 
>> guessing what went 
>> wrong.  Or you can just keep it simple and have PF implementation just print 
>> out a warning 
>> that the slack bus exceeded its capacity.  Modifying the Jacobian was the 
>> first thing that
>> came to my mind but I am not sure if it provides anything in addition of a 
>> warning to user. 
>> 
>> Jovan
>> 
>> 
>> On Thu, Feb 18, 2016 at 3:25 AM, Jose Luis Marin <mari...@gridquant.com 
>> <mailto:mari...@gridquant.com>> wrote:
>> But you did that, it would no longer be a powerflow calculation.  There are 
>> good mathematical reasons why the standard powerflow calculation is 
>> formulated so that there should be at least one swing bus (where you specify 
>> both V and A, leaving P and Q "free").  If you specified V, A, and Pgen at 
>> the swing, this would yield an overdetermined system.  You could 
>> theoretically formulate a powerflow in which the swing bus specified only A 
>> (the global angle reference) and Pgen, leaving Vref and Qgen free, but this 
>> would yield a system of equations with a severe pathology, namely a 
>> near-singular Jacobian (this originates from the fact that the full 
>> transmission admittance matrix, being a Laplacian matrix, always has a zero 
>> eigenvalue, which corresponds to a translation symmetry consisting in 
>> uniformly shifting all voltages;  pinning down at least one voltage is what 
>> breaks this symmetry and recovers invertibility).
>> 
>> However, I think you're right it would be a good idea to *warn* the user 
>> when the swing generator(s) have gone over their PMAX (or below their PMIN!).
>> 
>> -- 
>> Jose L. Marin
>> Grupo AIA
>> 
>> 
>> On Thu, Feb 18, 2016 at 12:08 AM, Jovan Ilic <jovan.i...@gmail.com 
>> <mailto:jovan.i...@gmail.com>> wrote:
>> 
>> Good point, maybe we should trow a Pgen constraint on the swing buses in the 
>> Jacobian. 
>> 
>>  
>> 
>> On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres <santiago.i...@gmail.com 
>> <mailto:santiago.i...@gmail.com>> wrote:
>> Because the exceding generation is supplied by the swing bus. Normal power 
>> flow does not check power generation limits.
>> 
>> El 17 feb. 2016 1:58 PM, "Bai, Wenlei" <wenlei_...@baylor.edu 
>> <mailto:wenlei_...@baylor.edu>> escribió:
>> Dear Ray,
>> 
>> I tried to modified load of ‘case9’ to exceed the total generation capacity 
>> purposely.
>> 
>> To my surprise, power flow still converges.  More specifically,  the total 
>> generator ‘on-line capacity’ is 820MW, while the ‘actual generation’ is 
>> 920.8MW
>> 
>> Why the actual generation can be larger than its capacity?
>> 
>>  
>> 
>> Blessings,
>> Wenlei
>> 
>>  
>> 
>> 
>> 
>> 
> 

Re: power flow question

[Abhyankar, Shrirang G.]

I agree. Having the warnings for all generators, voltages, etc. would be 
helpful for the cases when users are also varying the generation on PV buses. I 
would even like MATPOWER fixing the active power at PV buses to the max. or 
min. limit, if the generation exceeds these limits, and informing the users via 
a warning.

Shri

From: Ray Zimmerman <r...@cornell.edu<mailto:r...@cornell.edu>>
Reply-To: MATPOWER discussion forum 
<matpowe...@list.cornell.edu<mailto:matpowe...@list.cornell.edu>>
List-Post: matpower-l@cornell.edu
Date: Thursday, February 18, 2016 at 10:34 AM
To: MATPOWER discussion forum 
<matpowe...@list.cornell.edu<mailto:matpowe...@list.cornell.edu>>
Subject: Re: power flow question

I agree that checking for exceeded limits and warning about them would be a 
nice feature to add to the the power flow. I see no reason, though, why it 
should be limited to the swing bus power injection … why not include all of the 
other generator, voltage and branch flow limits, all of which can be violated 
in a converged power flow solution.

I’ll put it on the “to do” list.

   Ray


On Feb 18, 2016, at 8:05 AM, Jovan Ilic 
<jovan.i...@gmail.com<mailto:jovan.i...@gmail.com>> wrote:


Jose,

I did not suggest to turn the swing bus into a PV bus. There should be at least 
one swing bus
in the system unless you formulate your PF problem as ACOPF problem which does 
not need
any slack buses.

I understand what you are saying and you are right. I'd keep the swing bus as 
it is just
to provide the angle reference (admittance matrix is rarely singular) and add 
to Jacobian a
constraint on the sum of P and Q flows on the lines connected to the swing bus. 
 The sum
of all these lines out flows must be less than the power injection capability 
of the swing bus,
both P and Q. If the constraint is violated the power flow does not converge. 
The original
poster was concerned with the convergence when there is not enough generation, 
so
no convergence would give them a really stern "warning" and leave them guessing 
what went
wrong.  Or you can just keep it simple and have PF implementation just print 
out a warning
that the slack bus exceeded its capacity.  Modifying the Jacobian was the first 
thing that
came to my mind but I am not sure if it provides anything in addition of a 
warning to user.

Jovan


On Thu, Feb 18, 2016 at 3:25 AM, Jose Luis Marin 
<mari...@gridquant.com<mailto:mari...@gridquant.com>> wrote:
But you did that, it would no longer be a powerflow calculation.  There are 
good mathematical reasons why the standard powerflow calculation is formulated 
so that there should be at least one swing bus (where you specify both V and A, 
leaving P and Q "free").  If you specified V, A, and Pgen at the swing, this 
would yield an overdetermined system.  You could theoretically formulate a 
powerflow in which the swing bus specified only A (the global angle reference) 
and Pgen, leaving Vref and Qgen free, but this would yield a system of 
equations with a severe pathology, namely a near-singular Jacobian (this 
originates from the fact that the full transmission admittance matrix, being a 
Laplacian matrix, always has a zero eigenvalue, which corresponds to a 
translation symmetry consisting in uniformly shifting all voltages;  pinning 
down at least one voltage is what breaks this symmetry and recovers 
invertibility).

However, I think you're right it would be a good idea to *warn* the user when 
the swing generator(s) have gone over their PMAX (or below their PMIN!).

--
Jose L. Marin
Grupo AIA


On Thu, Feb 18, 2016 at 12:08 AM, Jovan Ilic 
<jovan.i...@gmail.com<mailto:jovan.i...@gmail.com>> wrote:

Good point, maybe we should trow a Pgen constraint on the swing buses in the 
Jacobian.



On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres 
<santiago.i...@gmail.com<mailto:santiago.i...@gmail.com>> wrote:

Because the exceding generation is supplied by the swing bus. Normal power flow 
does not check power generation limits.

El 17 feb. 2016 1:58 PM, "Bai, Wenlei" 
<wenlei_...@baylor.edu<mailto:wenlei_...@baylor.edu>> escribió:
Dear Ray,
I tried to modified load of ‘case9’ to exceed the total generation capacity 
purposely.
To my surprise, power flow still converges.  More specifically,  the total 
generator ‘on-line capacity’ is 820MW, while the ‘actual generation’ is 920.8MW
Why the actual generation can be larger than its capacity?

Blessings,
Wenlei

Re: power flow question

[Jose Luis Marin]

Hi Jovan,

Sorry, I see I misundertood.  I had read your proposal as consisting in
adding an *equality* constraint, instead of an *inequality* constraint.

But as you say, I suspect that such thing would be equivalent to just
adding a simple post-calculation check and a warning to the user when PG is
out of bounds (PMIN, PMAX).

-- 
Jose L. Marin
Grupo AIA


On Thu, Feb 18, 2016 at 2:05 PM, Jovan Ilic  wrote:

>
> Jose,
>
> I did not suggest to turn the swing bus into a PV bus. There should be at
> least one swing bus
> in the system unless you formulate your PF problem as ACOPF problem which
> does not need
> any slack buses.
>
> I understand what you are saying and you are right. I'd keep the swing bus
> as it is just
> to provide the angle reference (admittance matrix is rarely singular) and
> add to Jacobian a
> constraint on the sum of P and Q flows on the lines connected to the swing
> bus.  The sum
> of all these lines out flows must be less than the power injection
> capability of the swing bus,
> both P and Q. If the constraint is violated the power flow does not
> converge. The original
> poster was concerned with the convergence when there is not enough
> generation, so
> no convergence would give them a really stern "warning" and leave them
> guessing what went
> wrong.  Or you can just keep it simple and have PF implementation just
> print out a warning
> that the slack bus exceeded its capacity.  Modifying the Jacobian was the
> first thing that
> came to my mind but I am not sure if it provides anything in addition of a
> warning to user.
>
> Jovan
>
>
> On Thu, Feb 18, 2016 at 3:25 AM, Jose Luis Marin 
> wrote:
>
>> But you did that, it would no longer be a powerflow calculation.  There
>> are good mathematical reasons why the standard powerflow calculation is
>> formulated so that there should be at least one swing bus (where you
>> specify both V and A, leaving P and Q "free").  If you specified V, A, and
>> Pgen at the swing, this would yield an overdetermined system.  You could
>> theoretically formulate a powerflow in which the swing bus specified only A
>> (the global angle reference) and Pgen, leaving Vref and Qgen free, but this
>> would yield a system of equations with a severe pathology, namely a
>> near-singular Jacobian (this originates from the fact that the full
>> transmission admittance matrix, being a Laplacian matrix, always has a zero
>> eigenvalue, which corresponds to a translation symmetry consisting in
>> uniformly shifting all voltages;  pinning down at least one voltage is what
>> breaks this symmetry and recovers invertibility).
>>
>> However, I think you're right it would be a good idea to *warn* the user
>> when the swing generator(s) have gone over their PMAX (or below their
>> PMIN!).
>>
>> --
>> Jose L. Marin
>> Grupo AIA
>>
>>
>> On Thu, Feb 18, 2016 at 12:08 AM, Jovan Ilic 
>> wrote:
>>
>>>
>>> Good point, maybe we should trow a Pgen constraint on the swing buses in
>>> the Jacobian.
>>>
>>>
>>>
>>> On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres <
>>> santiago.i...@gmail.com> wrote:
>>>
 Because the exceding generation is supplied by the swing bus. Normal
 power flow does not check power generation limits.
 El 17 feb. 2016 1:58 PM, "Bai, Wenlei" 
 escribió:

> Dear Ray,
>
> I tried to modified load of ‘case9’ to exceed the total generation
> capacity purposely.
>
> To my surprise, power flow still converges.  More specifically,  the
> total generator ‘on-line capacity’ is 820MW, while the ‘actual generation’
> is 920.8MW
>
> Why the actual generation can be larger than its capacity?
>
>
>
> Blessings,
> Wenlei
>
>
>

>>>
>>
>

Re: power flow question

[Jovan Ilic]

Jose,

I did not suggest to turn the swing bus into a PV bus. There should be at
least one swing bus
in the system unless you formulate your PF problem as ACOPF problem which
does not need
any slack buses.

I understand what you are saying and you are right. I'd keep the swing bus
as it is just
to provide the angle reference (admittance matrix is rarely singular) and
add to Jacobian a
constraint on the sum of P and Q flows on the lines connected to the swing
bus.  The sum
of all these lines out flows must be less than the power injection
capability of the swing bus,
both P and Q. If the constraint is violated the power flow does not
converge. The original
poster was concerned with the convergence when there is not enough
generation, so
no convergence would give them a really stern "warning" and leave them
guessing what went
wrong.  Or you can just keep it simple and have PF implementation just
print out a warning
that the slack bus exceeded its capacity.  Modifying the Jacobian was the
first thing that
came to my mind but I am not sure if it provides anything in addition of a
warning to user.

Jovan


On Thu, Feb 18, 2016 at 3:25 AM, Jose Luis Marin 
wrote:

> But you did that, it would no longer be a powerflow calculation.  There
> are good mathematical reasons why the standard powerflow calculation is
> formulated so that there should be at least one swing bus (where you
> specify both V and A, leaving P and Q "free").  If you specified V, A, and
> Pgen at the swing, this would yield an overdetermined system.  You could
> theoretically formulate a powerflow in which the swing bus specified only A
> (the global angle reference) and Pgen, leaving Vref and Qgen free, but this
> would yield a system of equations with a severe pathology, namely a
> near-singular Jacobian (this originates from the fact that the full
> transmission admittance matrix, being a Laplacian matrix, always has a zero
> eigenvalue, which corresponds to a translation symmetry consisting in
> uniformly shifting all voltages;  pinning down at least one voltage is what
> breaks this symmetry and recovers invertibility).
>
> However, I think you're right it would be a good idea to *warn* the user
> when the swing generator(s) have gone over their PMAX (or below their
> PMIN!).
>
> --
> Jose L. Marin
> Grupo AIA
>
>
> On Thu, Feb 18, 2016 at 12:08 AM, Jovan Ilic  wrote:
>
>>
>> Good point, maybe we should trow a Pgen constraint on the swing buses in
>> the Jacobian.
>>
>>
>>
>> On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres > > wrote:
>>
>>> Because the exceding generation is supplied by the swing bus. Normal
>>> power flow does not check power generation limits.
>>> El 17 feb. 2016 1:58 PM, "Bai, Wenlei"  escribió:
>>>
 Dear Ray,

 I tried to modified load of ‘case9’ to exceed the total generation
 capacity purposely.

 To my surprise, power flow still converges.  More specifically,  the
 total generator ‘on-line capacity’ is 820MW, while the ‘actual generation’
 is 920.8MW

 Why the actual generation can be larger than its capacity?



 Blessings,
 Wenlei



>>>
>>
>

Re: power flow question

[Jose Luis Marin]

But you did that, it would no longer be a powerflow calculation.  There are
good mathematical reasons why the standard powerflow calculation is
formulated so that there should be at least one swing bus (where you
specify both V and A, leaving P and Q "free").  If you specified V, A, and
Pgen at the swing, this would yield an overdetermined system.  You could
theoretically formulate a powerflow in which the swing bus specified only A
(the global angle reference) and Pgen, leaving Vref and Qgen free, but this
would yield a system of equations with a severe pathology, namely a
near-singular Jacobian (this originates from the fact that the full
transmission admittance matrix, being a Laplacian matrix, always has a zero
eigenvalue, which corresponds to a translation symmetry consisting in
uniformly shifting all voltages;  pinning down at least one voltage is what
breaks this symmetry and recovers invertibility).

However, I think you're right it would be a good idea to *warn* the user
when the swing generator(s) have gone over their PMAX (or below their
PMIN!).

-- 
Jose L. Marin
Grupo AIA


On Thu, Feb 18, 2016 at 12:08 AM, Jovan Ilic  wrote:

>
> Good point, maybe we should trow a Pgen constraint on the swing buses in
> the Jacobian.
>
>
>
> On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres 
> wrote:
>
>> Because the exceding generation is supplied by the swing bus. Normal
>> power flow does not check power generation limits.
>> El 17 feb. 2016 1:58 PM, "Bai, Wenlei"  escribió:
>>
>>> Dear Ray,
>>>
>>> I tried to modified load of ‘case9’ to exceed the total generation
>>> capacity purposely.
>>>
>>> To my surprise, power flow still converges.  More specifically,  the
>>> total generator ‘on-line capacity’ is 820MW, while the ‘actual generation’
>>> is 920.8MW
>>>
>>> Why the actual generation can be larger than its capacity?
>>>
>>>
>>>
>>> Blessings,
>>> Wenlei
>>>
>>>
>>>
>>
>

Re: power flow question

[Jovan Ilic]

Good point, maybe we should trow a Pgen constraint on the swing buses in
the Jacobian.



On Wed, Feb 17, 2016 at 5:30 PM, Santiago Torres 
wrote:

> Because the exceding generation is supplied by the swing bus. Normal power
> flow does not check power generation limits.
> El 17 feb. 2016 1:58 PM, "Bai, Wenlei"  escribió:
>
>> Dear Ray,
>>
>> I tried to modified load of ‘case9’ to exceed the total generation
>> capacity purposely.
>>
>> To my surprise, power flow still converges.  More specifically,  the
>> total generator ‘on-line capacity’ is 820MW, while the ‘actual generation’
>> is 920.8MW
>>
>> Why the actual generation can be larger than its capacity?
>>
>>
>>
>> Blessings,
>> Wenlei
>>
>>
>>
>

Re: power flow question

[Santiago Torres]

Because the exceding generation is supplied by the swing bus. Normal power
flow does not check power generation limits.
El 17 feb. 2016 1:58 PM, "Bai, Wenlei"  escribió:

> Dear Ray,
>
> I tried to modified load of ‘case9’ to exceed the total generation
> capacity purposely.
>
> To my surprise, power flow still converges.  More specifically,  the total
> generator ‘on-line capacity’ is 820MW, while the ‘actual generation’ is
> 920.8MW
>
> Why the actual generation can be larger than its capacity?
>
>
>
> Blessings,
> Wenlei
>
>
>

Re: power flow question

[Abhyankar, Shrirang G.]

Wenlei,
  The power flow routine in MATPOWER does not enforce generation limits on real 
power. Exceeding the capacity does not necessarily imply a divergence of the 
power flow.

Shri

From: , Wenlei >
Reply-To: MATPOWER discussion forum 
>
List-Post: matpower-l@cornell.edu
Date: Wednesday, February 17, 2016 at 12:57 PM
To: "matpower-l@cornell.edu" 
>
Subject: power flow question

Dear Ray,
I tried to modified load of ‘case9’ to exceed the total generation capacity 
purposely.
To my surprise, power flow still converges.  More specifically,  the total 
generator ‘on-line capacity’ is 820MW, while the ‘actual generation’ is 920.8MW
Why the actual generation can be larger than its capacity?

Blessings,
Wenlei

Re: Power flow-doubt

[Ray Zimmerman]

I’m afraid I don’t know without seeing the actual code.

Ray


> On Nov 30, 2015, at 3:22 PM, lydia edwin  wrote:
> 
> Thank you very much sir for your reply. I have made the corrections suggested 
> by you.  Reg. query 3, I have calculated Va as the product of Zbus and 
> injected currents. But I find that this Va is different from the power flow 
> output Vc (in which Pa and Qa are the inputs)
> 
> What could be the possible reason? Thanks
> 
> 
> On Mon, Nov 30, 2015 at 6:33 PM, Ray Zimmerman  > wrote:
> 1. Setting values of bus loads and voltages in code after loading from a case 
> file is fine.
> 2. See caseformat() 
>  
> or Table B-1 in the User’s Manual 
> . You 
> will see that the PD and QD columns in the bus matrix are in MW and MVAr, not 
> in p.u. So you will have to convert them by multiplying by mpc.baseMVA.
> 3. Your Va is a voltage angle in radians, Vc is the complex voltage.
> 
> As a MATPOWER “best practices”, I also suggest that you use the named 
> constants rather than numerical column indices when referencing columns of 
> the data matrices. See define_constants() 
> 
>  and the next to last paragraph in section 2.3.2 of the User’s Manual 
>  for more 
> details.
> 
> Ray
> 
> 
> 
> 
>> On Nov 26, 2015, at 5:35 AM, lydia edwin > > wrote:
>> 
>> Hello sir
>> 
>> I am a beginner in MATPOWER.  I wanted to solve a power flow problem using 
>> the IEEE_30 bus system. I have Va, Pa, Qa in pu quantities.  I used Pa and 
>> Qa as inputs and wanted to solve the AC power flow and check if I get Va.  I 
>> used the following code:
>> 
>> mpc=loadcase(case30); 
>> mpc.bus(:,3)=Pa; % Input Pa in pu
>> mpc.bus(:,4)=Qa; % Input Qa in pu
>> mpc.bus(1,8)=1; % slack bus voltage
>> mpc.bus(1,9)=0; % slack bus angle
>> results=runpf(mpc); % stored the results
>> Vm1=results.bus(:,8); % output voltage magnitude
>> Va1=results.bus(:,9)*pi/180; %output voltage angles
>> % convert the voltage from polar to cartesian
>> for j=1:length(Vm1)
>> [Vr1(j),Vr2(j)]=pol2cart(Va1(j), Vm1(j));
>> Vc(j)=Vr1(j)+ 1i*Vr2(j);
>> end
>> 
>> Queries: 
>> 1. Is the way I have coded right? Or should I create a separate case format?
>> 2. Can I input Pa and Qa in pu values?
>> 3. The output Vc that I get is not same as Va.
>> 
>> Please help. Thanks
>> Lydia Edwin
> 
> 

Re: Power flow-doubt

[Ray Zimmerman]

1. Setting values of bus loads and voltages in code after loading from a case 
file is fine.
2. See caseformat() 
 
or Table B-1 in the User’s Manual 
. You will 
see that the PD and QD columns in the bus matrix are in MW and MVAr, not in 
p.u. So you will have to convert them by multiplying by mpc.baseMVA.
3. Your Va is a voltage angle in radians, Vc is the complex voltage.

As a MATPOWER “best practices”, I also suggest that you use the named constants 
rather than numerical column indices when referencing columns of the data 
matrices. See define_constants() 

 and the next to last paragraph in section 2.3.2 of the User’s Manual 
 for more 
details.

Ray




> On Nov 26, 2015, at 5:35 AM, lydia edwin  wrote:
> 
> Hello sir
> 
> I am a beginner in MATPOWER.  I wanted to solve a power flow problem using 
> the IEEE_30 bus system. I have Va, Pa, Qa in pu quantities.  I used Pa and Qa 
> as inputs and wanted to solve the AC power flow and check if I get Va.  I 
> used the following code:
> 
> mpc=loadcase(case30); 
> mpc.bus(:,3)=Pa; % Input Pa in pu
> mpc.bus(:,4)=Qa; % Input Qa in pu
> mpc.bus(1,8)=1; % slack bus voltage
> mpc.bus(1,9)=0; % slack bus angle
> results=runpf(mpc); % stored the results
> Vm1=results.bus(:,8); % output voltage magnitude
> Va1=results.bus(:,9)*pi/180; %output voltage angles
> % convert the voltage from polar to cartesian
> for j=1:length(Vm1)
> [Vr1(j),Vr2(j)]=pol2cart(Va1(j), Vm1(j));
> Vc(j)=Vr1(j)+ 1i*Vr2(j);
> end
> 
> Queries: 
> 1. Is the way I have coded right? Or should I create a separate case format?
> 2. Can I input Pa and Qa in pu values?
> 3. The output Vc that I get is not same as Va.
> 
> Please help. Thanks
> Lydia Edwin

Re: power flow

[P E S N Raju]

Dear lavanya,
you can set options like pf.nr.max_it=n maximum number of iterations for
Newton’s method,
pf.fd.max_it=n maximum number of iterations for fast-decoupled method
pf.gs.max_it=n maximum number of iterations for Gauss-Seidel method
Here, n is number of iterations. for your case n=1. The following is
procedure
let us solving with NR method
mpopt = mpoption('pf.alg', 'NR', 'verbose', 3,'pf.nr.max_it',01);
results = runpf('casedata', mpopt);

On Thu, Apr 9, 2015 at 12:58 PM, lavanya arubolu arubolulava...@gmail.com
wrote:

  [image: Boxbe] https://www.boxbe.com/overview This message is eligible
 for Automatic Cleanup! (arubolulava...@gmail.com) Add cleanup rule
 https://www.boxbe.com/popup?url=https%3A%2F%2Fwww.boxbe.com%2Fcleanup%3Ftoken%3DsZLXHpaXHU2FNS%252F%252BOphCVftkhsxCLEhbt40DNNidbAxi%252FHLRtCkPLgJGRMrCi1%252Fx3WvMLgDdSR4ne%252FUxlF1j41Qek0%252BcVVJVH59Xb7Uz7TLL9qSvkWbkIhzzZw5MI%252FPQx6NJOTutjolkZ3rEPfyA4w%253D%253D%26key%3D7M%252F8ybi9VZc8sLD%252BONZFSMdaFB68VvUAwyVP%252BEvVP7I%253Dtc_serial=20968762482tc_rand=1208750980utm_source=stfutm_medium=emailutm_campaign=ANNO_CLEANUP_ADDutm_content=001
 | More info
 http://blog.boxbe.com/general/boxbe-automatic-cleanup?tc_serial=20968762482tc_rand=1208750980utm_source=stfutm_medium=emailutm_campaign=ANNO_CLEANUP_ADDutm_content=001

 Dear all,
I want to run power flow for single iteration, but in MATPOWER
 software if i give command like runpf(casedata) for each iteration update
 the values of V,delta and P and finally gives me single result. If i want
 to run power flow for single iteration what can i do. Does anyone know how
 to solve this type of problems kindly help me.
 Thank you




-- 
With warm Regards,

Research Scholar,
Indian Institute of Technology-Indore.

Re: power flow

[Jose Luis Marin]

Hello Lavanya,

I guess you could achieve this by setting pf.nr.max_it to 1 (or pf.fd.max
it or pf.gs.max it, depending on the powerflow method you use). See Table
4.2 in the Manual.

-- 
Jose L. Marin
Gridquant España SL
Grupo AIA


On Thu, Apr 9, 2015 at 9:28 AM, lavanya arubolu arubolulava...@gmail.com
wrote:

 Dear all,
I want to run power flow for single iteration, but in MATPOWER
 software if i give command like runpf(casedata) for each iteration update
 the values of V,delta and P and finally gives me single result. If i want
 to run power flow for single iteration what can i do. Does anyone know how
 to solve this type of problems kindly help me.
 Thank you

Re: Power Flow from a particular branch to be minimized when load is changed

[Nirav Shah]

Can you please show me an example? I am quite new to matpower.

Sorry for troubling you every time.


On Tue, Dec 10, 2013 at 9:23 AM, Ray Zimmerman r...@cornell.edu wrote:

 The power flow code in MATPOWER is pretty straightforward, so if you are
 familiar with the details of the algorithms and become familiar with the
 code, it should be quite possible.

 I suggest duplicating fdpf.m, for example, and making modifications to
 your copy.

 --
 Ray Zimmerman
 Senior Research Associate
 B30 Warren Hall, Cornell University, Ithaca, NY 14853
 phone: (607) 255-9645



 On Dec 9, 2013, at 10:18 PM, Nirav Shah niravshah1...@gmail.com wrote:

 Thank you very much sir.

 I have one more doubt. I am using newton-fast decoupled method to run a
 power flow.

 My work includes an extra column in Jacobian for (dp/dx) where x is for
 the frequency.

 Is it possible to add that column in Jacobain and run power flow to solve
 for dx as well?


 On Mon, Dec 9, 2013 at 2:38 PM, Ray Zimmerman r...@cornell.edu wrote:

 MATPOWER does not have a built-in option to minimize the flow of a
 specified line, but there are a few ways you could approach solving the
 problem …

 (1) Brute force, run an optimal power flow in a loop where you decrease
 the rating of the line in question at each iteration until the problem
 becomes infeasible. If your changes are small enough, the last feasible
 solution should be near the minimal flow in the line.

 (2) Use a DC OPF, and create a user-defined cost on the flow on the line
 in question.

 (3) Split the line in half, with a dummy bus in the middle. Split this
 dummy bus into 2 dummy buses (A and B) and put a generator at each to
 represent the flow. Constrain generation at A to equal the negative of
 generation at B, constrain voltages at A and B to be equal. Put a quadratic
 cost on the generators at A and B to force them toward zero.

 The first option is probably the least amount of work if it is a one-time
 simulation and the problem is small.

--
 Ray Zimmerman
 Senior Research Associate
 B30 Warren Hall, Cornell University, Ithaca, NY 14853
 phone: (607) 255-9645



 On Dec 9, 2013, at 1:18 PM, Nirav Shah niravshah1...@gmail.com wrote:

 Hi all,
 I want to minimize the power flow from a particular branch when I change
 the load and run power flow/ optimal power flow again.

 Is it possible? Please reply as early as possible.

 Thank you.

Re: Power flow divergence problem

[Ray Zimmerman]

I agree that it would be useful to have an function that does a series of 
checks for data issues such as the one you mention. I've added it to my to do 
list …

-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645




On Jan 21, 2013, at 11:08 PM, Hwachang SONG hcs...@seoultech.ac.kr wrote:

 Dear Prof. Zimmerman,
 
 Pertaining to the issue of divergence because of Jacobian singularity, I 
 found a kind of point that needs to be fixed or 
 needs the addition of preprocessing of power flow data (*.m) in Matpower. 
 
 Actually, the data I used before did not have isolated areas, even though the 
 problem came from some isolated areas. 
 
 During the process of runopf(), I've noticed that voltage magnitudes of some 
 buses were initialized by zero (0). 
 So I tried to find out what kind of buses had 0 voltage magnitudes, and then 
 they are:
 - The bus type of them is '2,' because there are generating buses. 
 - But in the generator data section in power flow data(*.m), their Qmax and 
 Qmin are all set to 0. 
   (In real system data, sometimes, they are set to 0. - Actually I converted 
 the system data in pti pss/e format into matpower format)
 
 So it seems like that in Matpower it would be better to give a certain 
 warning message for those generating buses with 0-Qmax and Qmin.
 
 After modifying them (making bus-type change to '1' and remove the related 
 data in gen. and gen. cost section), power flow and optimal power flow
 were performed properly. 
 
 Thank you. 
 
 Hwachang
 
 
 --- Original Message ---
 From : Ray Zimmermanr...@cornell.edu
 To : MATPOWER discussion forummatpower-l@list.cornell.edu
 Date : 2013/01/08 화요일 오전 1:41:59
 Subject : Re: Power flow divergence problem
 
 It really depends on why the matrix is singular … and I have no way to know. 
 My guess is that the most likely reason is an error in the input data 
 somewhere … an isolated bus or set of buses, a zero impedance branch … 
 something like that..
 
  
Ray
 
 
 -- 
 Ray Zimmerman
 Senior Research Associate
 419A Warren Hall, Cornell University, Ithaca, NY 14853
 phone: (607) 255-9645
 
 
 
  
 
 On Jan 5, 2013, at 6:39 PM, Dirk Van Hertem dirk.vanher...@ieee.org wrote:
 
 Hi,
 
 You can try to convert (part of) your loads from PQ loads to impedance loads 
 (shunt elements with the same P and Q at nominal voltage). This should help 
 making your matrix less singular. 
 
 Best regards,
 
 Dirk
 
 On 01/05/2013 01:33 PM, Hwachang SONG wrote:
 
 Dear Prof. Zimmerman, 
 
 Recently, I applied matpower power flow for a converted real power system 
 with 2018 buses. 
 But the simulation does not converge, with the following message:
 
 Warning: Matrix is singular to working precision. 
  In newtonpf at 109
   In runpf at 220
 
 And the bus voltages and angles are all NaN. 
 
 Is there any method to fix this problem?
 
 Thanks.
 
 Hwachang Song
 
 
 
 
 
 
 Hwachang SONG (Ph.D.)
 Associate Professor
 Dept. of Electrical and Information Engineering
 Seoul Nat'l Univ. of Science and Technology (SeoulTech)
 Republic of Korea
 Phone: +82-2-970-6403
 Mobile: +82-10-7322-4605 
 Fax: +82-2-978-2754
 
 
 
 -- 
 
 Dirk Van Hertem
 
 Assistant Professor
 
 Research division ELECTA
 
 Department of electrical engineering (ESAT)
 
 KU Leuven, Belgium
 
 dirk.vanher...@esat.kuleuven.beTel.: 003216372415
 
  
 
  
 
 
 
 
 Hwachang SONG (Ph.D.)
 Associate Professor
 Dept. of Electrical and Information Engineering
 Seoul Nat'l Univ. of Science and Technology (SeoulTech)
 Republic of Korea
 Phone: +82-2-970-6403
 Mobile: +82-10-7322-4605 
 Fax: +82-2-978-2754
 
 

Re: Re: Power flow divergence problem

[Hwachang SONG]

Dear Prof. Zimmerman,



Pertaining to the issue of divergence because of Jacobian singularity, I found 
a kind of point that needs to be fixed or 

needs the addition of preprocessing of power flow data (*.m) in Matpower. 



Actually, the data I used before did not have isolated areas, even though the 
problem came from some isolated areas. 



During the process of runopf(), I've noticed that voltage magnitudes of some 
buses were initialized by zero (0). 

So I tried to find out what kind of buses had 0 voltage magnitudes, and then 
they are:

- The bus type of them is '2,' because there are generating buses. 

- But in the generator data section in power flow data(*.m), their Qmax and 
Qmin are all set to 0. 

  (In real system data, sometimes, they are set to 0. - Actually I converted 
the system data in pti pss/e format into matpower format)



So it seems like that in Matpower it would be better to give a certain warning 
message for those generating buses with 0-Qmax and Qmin.



After modifying them (making bus-type change to '1' and remove the related data 
in gen. and gen. cost section), power flow and optimal power flow

were performed properly. 



Thank you. 



Hwachang





--- Original Message ---

From : Ray Zimmermanr...@cornell.edu

To : MATPOWER discussion forummatpower-l@list.cornell.edu

Date : 2013/01/08 화요일 오전 1:41:59

Subject : Re: Power flow divergence problem







It really depends on why the matrix is singular hellip; and I have 
no way to know. My guess is that the most likely reason is an error in the 
input data somewhere hellip; an isolated bus or set of buses, a zero impedance 
branch hellip; something like that..


 
   Ray







-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645





 



On Jan 5, 2013, at 6:39 PM, Dirk Van Hertem a target=_blank 
href=mailto:dirk.vanher...@ieee.org;dirk.vanher...@ieee.org wrote:



Hi,



You can try to convert (part of) your loads from PQ loads to 
impedance loads (shunt elements with the same P and Q at nominal voltage). This 
should help making your matrix less singular. 



Best regards,



Dirk



On 01/05/2013 01:33 PM, Hwachang SONG wrote: blockquote 
cite=mid:1844604402.1357389236977.JavaMail.root@webmail type=cite


..TerraceMsg { font-size: 12px; font-family:Dotum, Arial, Verdana, Sans-Serif;}

..Bold { font-weight: bold; }
 In newtonpf at 109

  In runpf at 220



And the bus voltages and angles are all NaN. 



Is there any method to fix this problem?



Thanks.



Hwachang Song













 


 
Hwachang SONG (Ph.D.)

Associate Professor

Dept. of Electrical and Information Engineering

Seoul Nat'l Univ. of Science and Technology (SeoulTech)

Republic of Korea

Phone: +82-2-970-6403

Mobile: +82-10-7322-4605 

Fax: +82-2-978-2754










-- 

Dirk Van Hertem

Assistant Professor

Research division ELECTA

Department of electrical engineering (ESAT)

KU Leuven, Belgium

a class=moz-txt-link-abbreviated target=_blank 
href=mailto:dirk.vanher...@esat.kuleuven.be;dirk.vanher...@esat.kuleuven.be   
 Tel.: 003216372415


 



 












Hwachang SONG (Ph.D.)
Associate Professor
Dept. of Electrical and Information Engineering
Seoul Nat#39;l Univ. of Science and Technology (SeoulTech)
Republic of Korea
Phone: +82-2-970-6403
Mobile: +82-10-7322-4605 
Fax: +82-2-978-2754

Re: Power flow divergence problem

[Ray Zimmerman]

It really depends on why the matrix is singular … and I have no way to know. My 
guess is that the most likely reason is an error in the input data somewhere … 
an isolated bus or set of buses, a zero impedance branch … something like that.

   Ray


-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645




On Jan 5, 2013, at 6:39 PM, Dirk Van Hertem dirk.vanher...@ieee.org wrote:

 Hi,
 
 You can try to convert (part of) your loads from PQ loads to impedance loads 
 (shunt elements with the same P and Q at nominal voltage). This should help 
 making your matrix less singular. 
 
 Best regards,
 
 Dirk
 
 On 01/05/2013 01:33 PM, Hwachang SONG wrote:
 
 Dear Prof. Zimmerman, 
 
 Recently, I applied matpower power flow for a converted real power system 
 with 2018 buses. 
 But the simulation does not converge, with the following message:
 
 Warning: Matrix is singular to working precision. 
  In newtonpf at 109
   In runpf at 220
 
 And the bus voltages and angles are all NaN. 
 
 Is there any method to fix this problem?
 
 Thanks.
 
 Hwachang Song
 
 
 
 
 
 
 Hwachang SONG (Ph.D.)
 Associate Professor
 Dept. of Electrical and Information Engineering
 Seoul Nat'l Univ. of Science and Technology (SeoulTech)
 Republic of Korea
 Phone: +82-2-970-6403
 Mobile: +82-10-7322-4605 
 Fax: +82-2-978-2754
 
 
 -- 
 Dirk Van Hertem
 Assistant Professor
 Research division ELECTA
 Department of electrical engineering (ESAT)
 KU Leuven, Belgium
 dirk.vanher...@esat.kuleuven.beTel.: 003216372415
 

Re: Re: Power flow divergence problem

[Hwachang SONG]

Thank you for your advise. 
There might be one or more isolated areas, because there are several splitted 
buses on the system.



Hwachang Song
--- Original Message ---
From: Ray Zimmermanr...@cornell.edu
To  : MATPOWER discussion forummatpower-l@list.cornell.edu
Date: 2013/01/08 화요일 오전 1:41:59
Subject : Re: Power flow divergence problem








Hwachang SONG (Ph.D.)
Associate Professor
Dept. of Electrical and Information Engineering
Seoul Nat#39;l Univ. of Science and Technology (SeoulTech)
Republic of Korea
Phone: +82-2-970-6403
Mobile: +82-10-7322-4605 
Fax: +82-2-978-2754

Re: Power flow divergence problem

[Shri]

Check if any buses are actually isolated but their bustype hasn't been set to 
isolated (4). 
On Jan 5, 2013, at 6:33 AM, Hwachang SONG wrote:

 Dear Prof. Zimmerman, 
 
 Recently, I applied matpower power flow for a converted real power system 
 with 2018 buses. 
 But the simulation does not converge, with the following message:
 
 Warning: Matrix is singular to working precision. 
  In newtonpf at 109
   In runpf at 220
 
 And the bus voltages and angles are all NaN. 
 
 Is there any method to fix this problem?
 
 Thanks.
 
 Hwachang Song
 
 
 
 
 Hwachang SONG (Ph.D.)
 Associate Professor
 Dept. of Electrical and Information Engineering
 Seoul Nat'l Univ. of Science and Technology (SeoulTech)
 Republic of Korea
 Phone: +82-2-970-6403
 Mobile: +82-10-7322-4605 
 Fax: +82-2-978-2754
 
 

Re: Power flow divergence problem

[Dirk Van Hertem]

Hi,

You can try to convert (part of) your loads from PQ loads to impedance
loads (shunt elements with the same P and Q at nominal voltage). This
should help making your matrix less singular.

Best regards,

Dirk

On 01/05/2013 01:33 PM, Hwachang SONG wrote:
 Dear Prof. Zimmerman,

 Recently, I applied matpower power flow for a converted real power
 system with 2018 buses.
 But the simulation does not converge, with the following message:

 Warning: Matrix is singular to working precision.
  In newtonpf at 109
 In runpf at 220

 And the bus voltages and angles are all NaN.

 Is there any method to fix this problem?

 Thanks.

 Hwachang Song





   
   Hwachang SONG (Ph.D.)
 Associate Professor
 Dept. of Electrical and Information Engineering
 Seoul Nat'l Univ. of Science and Technology (SeoulTech)
 Republic of Korea
 Phone: +82-2-970-6403
 Mobile: +82-10-7322-4605
 Fax: +82-2-978-2754




-- 
Dirk Van Hertem
Assistant Professor
Research division ELECTA
Department of electrical engineering (ESAT)
KU Leuven, Belgium
dirk.vanher...@esat.kuleuven.beTel.: 003216372415

Re: Power flow results question

[新浪VIP]

Hi Sam,
I guess your assignment is a typical OPF problem: you may be asked to optimize 
the location and capacity of caps considering investment cost, under the 
constrains of power flow equations, voltage intervals, etc.
Thus, I suggest you read the chapter about OPF in MATPOWER manual, which must 
be helpful.
Two connected key points:
1,How do you model your optimization problem: object and constrain?
2, How do you model your var device: its control object and constrain?

Shiyang Li

在 2012-4-22，3:11，Sam Hazim samnz2...@yahoo.co.nz 写道：

 i tried to use the cap cost function with gengcost and put capbank in bs 
 column,but if fails to work,any idea please
  
 thanks
 sam
 
 From: jrmoret...@yahoo.com jrmoret...@yahoo.com
 To: MATPOWER discussion forum matpower-l@list.cornell.edu 
 Sent: Saturday, 21 April 2012 9:57 AM
 Subject: Re: Power flow results question
 
 Bar
 Enviado desde mi dispositivo BlackBerry® de Claro Dominicana
 From: Sam Hazim samnz2...@yahoo.co.nz
 Sender: bounce-49184047-9651...@list.cornell.edu
 Date: Fri, 20 Apr 2012 13:07:04 -0700 (PDT)
 To: MATPOWER discussion forummatpower-l@list.cornell.edu
 ReplyTo: MATPOWER discussion forum matpower-l@list.cornell.edu
 Subject: Re: Power flow results question
 
 Thank you so much for your reply,
  
 If i put them under BS column. What about the cap banks cost function, i 
 can't put them under the gencost,, where can i put cap cost function?
  
  
 Thank you,
  
  
 From: Ray Zimmerman r...@cornell.edu
 To: MATPOWER Discussion List matpowe...@cornell.edu 
 Sent: Saturday, 21 April 2012 6:26 AM
 Subject: Re: Power flow results question
 
 Capacitors are constant impedance elements that should be added to the BS 
 column of the bus matrix, not to the gen matrix.
 
 Ray
 
 
 On Apr 20, 2012, at 1:33 AM, Sam Hazim wrote:
 
 
 
 
 
 Hi everyone,
 I am new to Matpower, i have some few questions about power flow .
  
 I have been given in my assignment some possible locations for capacitor 
 banks  to be placed on the system.
  
 1: I want to make sure, to include  any cap bank on any bus, is it correct 
 be placed within generator data matrix and set Pg,Qg,Qmin =0, vg=1,  Qgmax= 
 300 (value given in my assignment).
 2:  from my knowledge, we use cap banks order to minimize losses or support 
 voltage.i tried to connect them to the high voltage bus or to the main 
 transform, or other locations and then runpf. the answer doesn't change at 
 all ( Why is that). i have got min voltage at one bus is about 0.831 and it 
 should be between a recommend range 0.95 to 1.05.
  
 I have included the case file for two modified cases.and runpf , the results 
 are the same for both of them.
  
 Please, any suggestions will be very helpful for me to tackle this problem.
  
 Raad
  
 function mpc = case18
 %%- Power Flow Data -%%
 %% system MVA base
 mpc.baseMVA = 500;
 %% bus data
 % bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vmin
 mpc.bus = [
 1 3 0 0 0 0 1 1 0 220 1 1.05 0.95;
 2 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 3 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 4 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 5 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 6 1 200 50 0 0 1 1 0 220 1 1.05 0.95;
 7 1 450 115 0 0 1 1 0 220 1 1.05 0.95;
 8 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 9 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 10 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 11 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 12 1 200 50 0 0 1 1 0 110 1 1.05 0.95;
 13 1 150 40 0 0 2 1 0 110 1 1.05 0.95;
 14 1 250 65 0 0 2 1 0 110 1 1.05 0.95;
 15 1 750 190 0 0 2 1 0 110 1 1.05 0.95;
 16 2 0 0 0 0 2 1 0 33 1 1.05 0.95;
 17 1 0 0 0 0 2 1 0 220 1 1.05 0.95;
 18 2 0 0 0 0 2 1 0 110 1 1.05 0.95;
 ];
 %% generator data
 % bus Pg Qg Qmax Qmin Vg mBase status Pmax Pmin Pc1 Pc2 Qc1min Qc1max Qc2min 
 Qc2max ramp_agc ramp_10 ramp_30 ramp_q apf
 mpc.gen = [
 1 500 0 750 -200 1.05 500 1 1250 0 0 0 0 0 0 0 0 0 0 0 0;
 3 450 0 50 -150 1.05 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
 5 550 0 200 -150 1.028 500 1 600 0 0 0 0 0 0 0 0 0 0 0 0;
 8 50 0 65 -200 0.95 500 1 120 0 0 0 0 0 0 0 0 0 0 0 0;
 16 400 0 300 -40 1.022 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
 18 250 0 220 -100 0.99 500 1 350 0 0 0 0 0 0 0 0 0 0 0 0;
 9 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 12 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 13 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 14 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 15 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 ];
 %% branch data
 % fbus tbus r x b rateA rateB rateC ratio angle status
 mpc.branch = [
 1 3 0.0712 0.3595 0.0982 524 0 0 0 0 1;
 4 5 0.0978 0.5855 0.0773 455 0 0 0 0 1;
 4 6 0.023 0.1615 0.01 671 0 0 0 0 1;
 4 7 0.0201 0.1548 0.0395 766 0 0 0 0 1;
 4 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
 7 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
 7 9 0.01 0.0954 0.0058 915 0 0 0 0 1;
 1 6 0.042 0.2715 0.017 493 0 0 0 0 1;
 1 7 0.088 0.5675 0.0356 323 0 0 0 0 1;
 1 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
 7 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
 7 18 0. 0.08 0.00 2000 0 0 1 0 1;
 7 8 0.002 0.0175 0.0011 915 0 0 0 0

Re: Power flow results question

[Hua Bowen]

I don't know whether you set the bus where your cap bank is located a
PQ bus or a PV bus. From the unchanged results I could guess that it's
a PQ bus. Keep in mind that when you do a simple load flow, voltage
limits and generator output limits are not considered. In your case,
Pg and Qg of the dummy generator are set to to zero. This leads to the
output of the generator being zero when you do the load flow (because
it is a PQ bus so the values of Pg and Qg are used). So the results
won't change.

Set the bus to a PV one. Then in load flow the capacitor will take
effect.Or simply do an OPF and all the limits will be considered.

Notice that in this way of modeling the cap banks, the capacity is
adjusted continuously.

Sorry, not a native speaker :) Hope this helps.

On Fri, Apr 20, 2012 at 1:33 PM, Sam Hazim samnz2...@yahoo.co.nz wrote:




 Hi everyone,
 I am new to Matpower, i have some few questions about power flow .

 I have been given in my assignment some possible locations for capacitor
 banks  to be placed on the system.

 1: I want to make sure, to include  any cap bank on any bus, is it correct
 be placed within generator data matrix and set Pg,Qg,Qmin =0, vg=1,  Qgmax=
 300 (value given in my assignment).
 2:  from my knowledge, we use cap banks order to minimize losses or support
 voltage.i tried to connect them to the high voltage bus or to the main
 transform, or other locations and then runpf. the answer doesn't change at
 all ( Why is that). i have got min voltage at one bus is about 0.831 and it
 should be between a recommend range 0.95 to 1.05.

 I have included the case file for two modified cases.and runpf , the results
 are the same for both of them.

 Please, any suggestions will be very helpful for me to tackle this problem.

 Raad

 function
 mpc = case18
 %%- Power Flow Data -%%
 %% system MVA base
 mpc.baseMVA = 500;
 %% bus data
 % bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vmin
 mpc.bus = [
 1 3 0 0 0 0 1 1 0 220 1 1.05 0.95;
 2 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 3 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 4 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 5 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 6 1 200 50 0 0 1 1 0 220 1 1.05 0.95;
 7 1 450 115 0 0 1 1 0 220 1 1.05 0.95;
 8 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
 9 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 10 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 11 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
 12 1 200 50 0 0 1 1 0 110 1 1.05 0.95;
 13 1 150 40 0 0 2 1 0 110 1 1.05 0.95;
 14 1 250 65 0 0 2 1 0 110 1 1.05 0.95;
 15 1 750 190 0 0 2 1 0 110 1 1.05 0.95;
 16 2 0 0 0 0 2 1 0 33 1 1.05 0.95;
 17 1 0 0 0 0 2 1 0 220 1 1.05 0.95;
 18 2 0 0 0 0 2 1 0 110 1 1.05 0.95;
 ];
 %% generator data
 % bus Pg Qg Qmax Qmin Vg mBase status Pmax Pmin Pc1 Pc2 Qc1min Qc1max Qc2min
 Qc2max ramp_agc ramp_10 ramp_30 ramp_q apf
 mpc.gen = [
 1 500 0 750 -200 1.05 500 1 1250 0 0 0 0 0 0 0 0 0 0 0 0;
 3 450 0 50 -150 1.05 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
 5 550 0 200 -150 1.028 500 1 600 0 0 0 0 0 0 0 0 0 0 0 0;
 8 50 0 65 -200 0.95 500 1 120 0 0 0 0 0 0 0 0 0 0 0 0;
 16 400 0 300 -40 1.022 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
 18 250 0 220 -100 0.99 500 1 350 0 0 0 0 0 0 0 0 0 0 0 0;
 9 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 12 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 13 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 14 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 15 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
 ];
 %% branch data
 % fbus tbus r x b rateA rateB rateC ratio angle status
 mpc.branch = [
 1 3 0.0712 0.3595 0.0982 524 0 0 0 0 1;
 4 5 0.0978 0.5855 0.0773 455 0 0 0 0 1;
 4 6 0.023 0.1615 0.01 671 0 0 0 0 1;
 4 7 0.0201 0.1548 0.0395 766 0 0 0 0 1;
 4 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
 7 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
 7 9 0.01 0.0954 0.0058 915 0 0 0 0 1;
 1 6 0.042 0.2715 0.017 493 0 0 0 0 1;
 1 7 0.088 0.5675 0.0356 323 0 0 0 0 1;
 1 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
 7 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
 7 18 0. 0.08 0.00 2000 0 0 1 0 1;
 7 8 0.002 0.0175 0.0011 915 0 0 0 0 1;
 7 15 0. 0.05 0.00 2000 0 0 1 0 1;
 8 9 0.009 0.0775 0.0047 915 0 0 0 0 1;
 9 10 0.0095 0.078 0.005 827 0 0 0 0 1;
 9 11 0.079 0.4815 0.0191 408 0 0 0 0 1;
 9 14 0.00 0.15 0.00 2000 0 0 1 0 1;
 10 11 0.044 0.3585 0.0233 456 0 0 0 0 1;
 10 12 0. 0.15 0.00 2000 0 0 1 0 1;
 11 13 0.0 0.30 0.00 2000 0 0 1 0 1;
 4 16 0.00 0.131 0.00 2000 0 0 1 0 1;
 3 5 0.036 0.2396 0.0667 870 0 0 0 0 1;
 ];
 %%- OPF Data -%%
 %% generator cost data
 % 1 startup shutdown n x1 y1 ... xn yn
 % 2 startup shutdown n c(n-1) ... c0
 mpc.gencost = [
 2 0 0 3 0.039 20 0;
 2 0 0 3 0.029 20 0;
 2 0 0 3 0.031 20 0;
 2 0 0 3 0.12 20 0;
 2 0 0 3 0.25 20 0;
 2 0 0 3 0.1 20 0;
 2 0.01 0 3 0.01 40 0;
 2 0.01 0 3 0.01 40 0;
 2 0.01 0 3 0.01 40 0;
 2 0.01 0 3 0.01 40 0;
 2 0.01 0 3 0.01 40 0;
 ];

 This is the  modifed case

 function
 mpc = case18
 %%- Power Flow Data -%%
 %% system MVA base
 mpc.baseMVA = 500;
 %% bus data
 % bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vmin
 

Re: Power flow results question

[Sam Hazim]

Thank you so much for your reply,
 
If i put them under BS column. What about the cap banks cost function, i can't 
put them under the gencost,, where can i put cap cost function?
 
 
Thank you,
 
 
From: Ray Zimmerman r...@cornell.edu
To: MATPOWER Discussion List matpowe...@cornell.edu 
Sent: Saturday, 21 April 2012 6:26 AM
Subject: Re: Power flow results question


Capacitors are constant impedance elements that should be added to the BS 
column of the bus matrix, not to the gen matrix. 

    Ray




On Apr 20, 2012, at 1:33 AM, Sam Hazim wrote:










Hi everyone,
I am new to Matpower, i have some few questions about power flow .

I have been given in my assignment some possible locations for capacitor banks 
 to be placed on the system.

1: I want to make sure, to include  any cap bank on any bus, is it correct be 
placed within generator data matrix and set Pg,Qg,Qmin =0, vg=1,  Qgmax= 300 
(value given in my assignment).
2:  from my knowledge, we use cap banks order to minimize losses or support 
voltage.i tried to connect them to the high voltage bus or to the main 
transform, or other locations and then runpf. the answer doesn't change at all 
( Why is that). i have got min voltage at one bus is about 0.831 and it should 
be between a recommend range 0.95 to 1.05.

I have included the case file for two modified cases.and runpf , the results 
are the same for both of them.

Please, any suggestions will be very helpful for me to tackle this problem.

Raad

functionmpc = case18%%- Power Flow Data -%%
%% system MVA basempc.baseMVA = 500;%% bus data
% bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vminmpc.bus = [
1 3 0 0 0 0 1 1 0 220 1 1.05 0.95;
2 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
3 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
4 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
5 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
6 1 200 50 0 0 1 1 0 220 1 1.05 0.95;
7 1 450 115 0 0 1 1 0 220 1 1.05 0.95;
8 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
9 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
10 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
11 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
12 1 200 50 0 0 1 1 0 110 1 1.05 0.95;
13 1 150 40 0 0 2 1 0 110 1 1.05 0.95;
14 1 250 65 0 0 2 1 0 110 1 1.05 0.95;
15 1 750 190 0 0 2 1 0 110 1 1.05 0.95;
16 2 0 0 0 0 2 1 0 33 1 1.05 0.95;
17 1 0 0 0 0 2 1 0 220 1 1.05 0.95;
18 2 0 0 0 0 2 1 0 110 1 1.05 0.95;
];%% generator data
% bus Pg Qg Qmax Qmin Vg mBase status Pmax Pmin Pc1 Pc2 Qc1min Qc1max Qc2min 
Qc2max ramp_agc ramp_10 ramp_30 ramp_q apfmpc.gen = [
1 500 0 750 -200 1.05 500 1 1250 0 0 0 0 0 0 0 0 0 0 0 0;
3 450 0 50 -150 1.05 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
5 550 0 200 -150 1.028 500 1 600 0 0 0 0 0 0 0 0 0 0 0 0;
8 50 0 65 -200 0.95 500 1 120 0 0 0 0 0 0 0 0 0 0 0 0;
16 400 0 300 -40 1.022 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
18 250 0 220 -100 0.99 500 1 350 0 0 0 0 0 0 0 0 0 0 0 0;
9 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
12 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
13 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
14 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
15 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
];%% branch data
% fbus tbus r x b rateA rateB rateC ratio angle status mpc.branch = [
1 3 0.0712 0.3595 0.0982 524 0 0 0 0 1;
4 5 0.0978 0.5855 0.0773 455 0 0 0 0 1;
4 6 0.023 0.1615 0.01 671 0 0 0 0 1;
4 7 0.0201 0.1548 0.0395 766 0 0 0 0 1;
4 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
7 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
7 9 0.01 0.0954 0.0058 915 0 0 0 0 1;
1 6 0.042 0.2715 0.017 493 0 0 0 0 1;
1 7 0.088 0.5675 0.0356 323 0 0 0 0 1;
1 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
7 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
7 18 0. 0.08 0.00 2000 0 0 1 0 1;
7 8 0.002 0.0175 0.0011 915 0 0 0 0 1;
7 15 0. 0.05 0.00 2000 0 0 1 0 1;
8 9 0.009 0.0775 0.0047 915 0 0 0 0 1;
9 10 0.0095 0.078 0.005 827 0 0 0 0 1;
9 11 0.079 0.4815 0.0191 408 0 0 0 0 1;
9 14 0.00 0.15 0.00 2000 0 0 1 0 1;
10 11 0.044 0.3585 0.0233 456 0 0 0 0 1;
10 12 0. 0.15 0.00 2000 0 0 1 0 1;
11 13 0.0 0.30 0.00 2000 0 0 1 0 1;
4 16 0.00 0.131 0.00 2000 0 0 1 0 1;
3 5 0.036 0.2396 0.0667 870 0 0 0 0 1;
];%%- OPF Data -%%
%% generator cost data
% 1 startup shutdown n x1 y1 ... xn yn
% 2 startup shutdown n c(n-1) ... c0mpc.gencost = [
2 0 0 3 0.039 20 0;
2 0 0 3 0.029 20 0;
2 0 0 3 0.031 20 0;
2 0 0 3 0.12 20 0;
2 0 0 3 0.25 20 0;
2 0 0 3 0.1 20 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
];

This is the  modifed case

functionmpc = case18%%- Power Flow Data -%%
%% system MVA basempc.baseMVA = 500;%% bus data
% bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vminmpc.bus = [
1 3 0 0 0 0 1 1 0 220 1 1.05 0.95;
2 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
3 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
4 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
5 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
6 1 200 50 0 0 1 1 0 220 1 1.05 0.95;
7 1 450 115 0 0 1 1 0 220 1 1.05 0.95;
8 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
9 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
10 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
11 1

Re: Power flow results question

[jrmoreta29]

F 
Enviado desde mi dispositivo BlackBerry® de Claro Dominicana

-Original Message-
From: Sam Hazim samnz2...@yahoo.co.nz
Sender: bounce-49184047-9651...@list.cornell.edu
Date: Fri, 20 Apr 2012 13:07:04 
To: MATPOWER discussion forummatpower-l@list.cornell.edu
Reply-To: MATPOWER discussion forum matpower-l@list.cornell.edu
Subject: Re: Power flow results question

Thank you so much for your reply,
 
If i put them under BS column. What about the cap banks cost function, i can't 
put them under the gencost,, where can i put cap cost function?
 
 
Thank you,
 
 
From: Ray Zimmerman r...@cornell.edu
To: MATPOWER Discussion List matpowe...@cornell.edu 
Sent: Saturday, 21 April 2012 6:26 AM
Subject: Re: Power flow results question


Capacitors are constant impedance elements that should be added to the BS 
column of the bus matrix, not to the gen matrix. 

    Ray




On Apr 20, 2012, at 1:33 AM, Sam Hazim wrote:










Hi everyone,
I am new to Matpower, i have some few questions about power flow .

I have been given in my assignment some possible locations for capacitor banks 
 to be placed on the system.

1: I want to make sure, to include  any cap bank on any bus, is it correct be 
placed within generator data matrix and set Pg,Qg,Qmin =0, vg=1,  Qgmax= 300 
(value given in my assignment).
2:  from my knowledge, we use cap banks order to minimize losses or support 
voltage.i tried to connect them to the high voltage bus or to the main 
transform, or other locations and then runpf. the answer doesn't change at all 
( Why is that). i have got min voltage at one bus is about 0.831 and it should 
be between a recommend range 0.95 to 1.05.

I have included the case file for two modified cases.and runpf , the results 
are the same for both of them.

Please, any suggestions will be very helpful for me to tackle this problem.

Raad

functionmpc = case18%%- Power Flow Data -%%
%% system MVA basempc.baseMVA = 500;%% bus data
% bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vminmpc.bus = [
1 3 0 0 0 0 1 1 0 220 1 1.05 0.95;
2 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
3 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
4 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
5 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
6 1 200 50 0 0 1 1 0 220 1 1.05 0.95;
7 1 450 115 0 0 1 1 0 220 1 1.05 0.95;
8 2 0 0 0 0 1 1 0 220 1 1.05 0.95;
9 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
10 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
11 1 0 0 0 0 1 1 0 220 1 1.05 0.95;
12 1 200 50 0 0 1 1 0 110 1 1.05 0.95;
13 1 150 40 0 0 2 1 0 110 1 1.05 0.95;
14 1 250 65 0 0 2 1 0 110 1 1.05 0.95;
15 1 750 190 0 0 2 1 0 110 1 1.05 0.95;
16 2 0 0 0 0 2 1 0 33 1 1.05 0.95;
17 1 0 0 0 0 2 1 0 220 1 1.05 0.95;
18 2 0 0 0 0 2 1 0 110 1 1.05 0.95;
];%% generator data
% bus Pg Qg Qmax Qmin Vg mBase status Pmax Pmin Pc1 Pc2 Qc1min Qc1max Qc2min 
Qc2max ramp_agc ramp_10 ramp_30 ramp_q apfmpc.gen = [
1 500 0 750 -200 1.05 500 1 1250 0 0 0 0 0 0 0 0 0 0 0 0;
3 450 0 50 -150 1.05 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
5 550 0 200 -150 1.028 500 1 600 0 0 0 0 0 0 0 0 0 0 0 0;
8 50 0 65 -200 0.95 500 1 120 0 0 0 0 0 0 0 0 0 0 0 0;
16 400 0 300 -40 1.022 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0;
18 250 0 220 -100 0.99 500 1 350 0 0 0 0 0 0 0 0 0 0 0 0;
9 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
12 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
13 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
14 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
15 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0;
];%% branch data
% fbus tbus r x b rateA rateB rateC ratio angle status mpc.branch = [
1 3 0.0712 0.3595 0.0982 524 0 0 0 0 1;
4 5 0.0978 0.5855 0.0773 455 0 0 0 0 1;
4 6 0.023 0.1615 0.01 671 0 0 0 0 1;
4 7 0.0201 0.1548 0.0395 766 0 0 0 0 1;
4 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
7 2 0.0112 0.1136 0.0071 766 0 0 0 0 1;
7 9 0.01 0.0954 0.0058 915 0 0 0 0 1;
1 6 0.042 0.2715 0.017 493 0 0 0 0 1;
1 7 0.088 0.5675 0.0356 323 0 0 0 0 1;
1 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
7 17 0.0444 0.2104 0.0247 323 0 0 0 0 1;
7 18 0. 0.08 0.00 2000 0 0 1 0 1;
7 8 0.002 0.0175 0.0011 915 0 0 0 0 1;
7 15 0. 0.05 0.00 2000 0 0 1 0 1;
8 9 0.009 0.0775 0.0047 915 0 0 0 0 1;
9 10 0.0095 0.078 0.005 827 0 0 0 0 1;
9 11 0.079 0.4815 0.0191 408 0 0 0 0 1;
9 14 0.00 0.15 0.00 2000 0 0 1 0 1;
10 11 0.044 0.3585 0.0233 456 0 0 0 0 1;
10 12 0. 0.15 0.00 2000 0 0 1 0 1;
11 13 0.0 0.30 0.00 2000 0 0 1 0 1;
4 16 0.00 0.131 0.00 2000 0 0 1 0 1;
3 5 0.036 0.2396 0.0667 870 0 0 0 0 1;
];%%- OPF Data -%%
%% generator cost data
% 1 startup shutdown n x1 y1 ... xn yn
% 2 startup shutdown n c(n-1) ... c0mpc.gencost = [
2 0 0 3 0.039 20 0;
2 0 0 3 0.029 20 0;
2 0 0 3 0.031 20 0;
2 0 0 3 0.12 20 0;
2 0 0 3 0.25 20 0;
2 0 0 3 0.1 20 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
2 0.01 0 3 0.01 40 0;
];

This is the  modifed case

functionmpc = case18%%- Power Flow Data -%%
%% system MVA basempc.baseMVA = 500;%% bus data
% bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax

Re: Power Flow in a horizon year with load growth

[Ray Zimmerman]

MATPOWER simply solves a power flow or optimal power flow. If you can specify 
the inputs to correspond to whatever you mean by power flow in a given horizon 
year, then the answer is yes. MATPOWER will not automatically set up such 
inputs for you, but you should certainly be able to scale the loads before 
running the power flow. See 'help scale_load' for more details.

-- 
Ray Zimmerman
Senior Research Associate
419A Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645




On Apr 19, 2012, at 10:28 AM, iman wrote:

 Dear All,
 
 Is MATPOWER cabaple of implementing power flow in a given horizon year (e.g. 
 5 years) considering load growth?
 
 -- 
 Best regards
 Iman
 

Re: Power Flow Convergence Problem: RTS-96 Test System

[Esmaeil Ghahremani]

Dear Professor Zimmerman

Thank you so much for you help and guidance.
It helps me so much and it works fine.

All the Best

Esmaeil Ghahremani




From: Ray Zimmerman r...@cornell.edu
To: MATPOWER discussion forum matpower-l@list.cornell.edu
Sent: Fri, July 8, 2011 4:32:19 PM
Subject: Re: Power Flow Convergence Problem: RTS-96 Test System


It appears to be related to the voltage setpoints for the generators. If you 
solve the OPF (which allows the generator voltages to vary between VMIN and 
VMAX) and then use the voltages from that solution as the setpoints in gen(:, 
VG), then the power flow solves fine.

-- 
Ray Zimmerman
Senior Research Associate
211 Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645



On Jul 7, 2011, at 3:34 PM, Esmaeil Ghahremani wrote:

Hello All Dear Matpower Users,


The RTS-96 Test System data could be found from this link:
http://www.ee.washington.edu/research/pstca/rts/pg_tcarts.htm


From google searching, I have found the following link for the Matpower format 
of RTS-96 Test system: 
http://www.parallelcoding.com/wp-content/uploads/Research/MCSPruning/case96.m


I rearranged the above file in the form of attached file (They are exactly the 
same). I just insert them in the format of Matpower. 


By using this case, I am surprised that while I run the Power Flow command as:


 opt = mpoption('VERBOSE', 2, 'OUT_ALL', 0);
  runpf('case96', opt); 


It does not converge. 



While when I run OPF as: 


 opt = mpoption('VERBOSE', 2, 'OUT_ALL', 0);
  runopf('case96', opt); 


The OPF converges. 


Could anyone help me in this case ? Why we have results in OPF but we dont 
have 
in PF ? 
What would be the problem in  runpf  for Power Flow command ?
Do you think that could be any error in the case study file ?


All the Best
Esmaeil 




P.S. 
If anyone has another case study file for RTS-96 Test system, I would like to 
have it.

case96.m

Re: Power Flow Convergence Problem: RTS-96 Test System

[Ray Zimmerman]

It appears to be related to the voltage setpoints for the generators. If you 
solve the OPF (which allows the generator voltages to vary between VMIN and 
VMAX) and then use the voltages from that solution as the setpoints in gen(:, 
VG), then the power flow solves fine.

-- 
Ray Zimmerman
Senior Research Associate
211 Warren Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645



On Jul 7, 2011, at 3:34 PM, Esmaeil Ghahremani wrote:

 Hello All Dear Matpower Users,
 
 The RTS-96 Test System data could be found from this link:
 http://www.ee.washington.edu/research/pstca/rts/pg_tcarts.htm
 
 From google searching, I have found the following link for the Matpower 
 format of RTS-96 Test system: 
 http://www.parallelcoding.com/wp-content/uploads/Research/MCSPruning/case96.m
 
 I rearranged the above file in the form of attached file (They are exactly 
 the same). I just insert them in the format of Matpower. 
 
 By using this case, I am surprised that while I run the Power Flow command as:
 
  opt = mpoption('VERBOSE', 2, 'OUT_ALL', 0);
   runpf('case96', opt); 
 
 It does not converge. 
 
 While when I run OPF as: 
 
  opt = mpoption('VERBOSE', 2, 'OUT_ALL', 0);
   runopf('case96', opt); 
 
 The OPF converges. 
 
 Could anyone help me in this case ? Why we have results in OPF but we dont 
 have in PF ? 
 What would be the problem in  runpf  for Power Flow command ?
 Do you think that could be any error in the case study file ?
 
 All the Best
 Esmaeil 
 
 
 P.S. 
 If anyone has another case study file for RTS-96 Test system, I would like to 
 have it.
 
 case96.m