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<https://github.com/MATPOWER/matpower> (to download, click the green 
“Code” button, then select “Download ZIP”), or
2) download the latest 
radial_pf.m<https://github.com/MATPOWER/matpower/blob/master/lib/radial_pf.m> 
(and 
t/t_pf_radial.m<https://github.com/MATPOWER/matpower/blob/master/lib/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<https://github.com/MATPOWER/matpower/issues/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<http://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
<https://github.com/MATPOWER/matpower/issues/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<https://github.com/MATPOWER/matpower/issues>?

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]
>

Power Flow Calculation Error

[Muhammad Junaid]

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: Regarding storing of the result from optimal power flow

[Ray Daniel Zimmerman]

See Section 6.6 in the MATPOWER User’s 
Manual, especially Table 6-1.

There are a few things, like losses, that are displayed in the console output, 
that are not included in the results struct. These can be computed using 
get_losses().

   Ray

On Feb 12, 2023, at 12:17 AM, Nirban Chakraborty  
wrote:


Respected sir,
As I am running any case file in matpower let's say case 33 for 
finding the opf it is showing the result as bus data and branch data. But how 
store those data in matlab workspace, so that I can write a program using those 
data. Please help me out in this regard.

Regarding storing of the result from optimal power flow

[Nirban Chakraborty]

Respected sir,
As I am running any case file in matpower let's say case 33
for finding the opf it is showing the result as bus data and branch data.
But how store those data in matlab workspace, so that I can write a program
using those data. Please help me out in this regard.

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
>

Power flow and generation power limit

[Muhammad Nadeem]

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: Query in power flow analysis of radial distribution system with two voltage levels

[Irfan Mujawar]

Ok.
Will check that.

On Tue, 22 Nov, 2022, 1:08 am Ray Daniel Zimmerman, 
wrote:

> If you convert everything into per-unit correctly, using a different
> voltage base for the different buses, it shouldn’t be a problem. I suggest
> finding a good textbook on converting parameters to per-unit to make sure
> you get it right, especially for the transformer.
>
> Ray
>
>
> > On Nov 7, 2022, at 12:56 PM, Irfan Mujawar 
> wrote:
> >
> > I want to use the MATPOWER for load flow analysis of the practical
> radial distribution system.
> > In the system two voltage levels are there.
> > First is 11 kV bus (Bus 1) which is slack bus.
> > All other buses are of 440V bus.
> > There is a transformer of 11kV/440V  between bus 1 and 2.
> > From bus 2 onwards are load bus.
> > At some buses load is present at some buses no load is present.
> > I know the values of R and X of line in ohm.
> > How to perform the load flow analysis of this system having two voltage
> levels with transformer?
> > How to proceed.
> >
> >  I am able to perform the load flow analysis of the system from 440V and
> downstream buses i.e. with one voltage level.
> > I am facing the problem when I make bus 1 as slack bus with 11 kV.
> >
> > When I have added the 11 kV line and performed the load flow total
> losses are less than that of load flow when only 440V line and downstream
> loads are present.
> >
> > I am not getting what is wrong.
> > Please help.
> > Thank you.
>
>

Re: Query in power flow analysis of radial distribution system with two voltage levels

[Ray Daniel Zimmerman]

If you convert everything into per-unit correctly, using a different voltage 
base for the different buses, it shouldn’t be a problem. I suggest finding a 
good textbook on converting parameters to per-unit to make sure you get it 
right, especially for the transformer.

Ray


> On Nov 7, 2022, at 12:56 PM, Irfan Mujawar  wrote:
> 
> I want to use the MATPOWER for load flow analysis of the practical radial 
> distribution system. 
> In the system two voltage levels are there.
> First is 11 kV bus (Bus 1) which is slack bus.
> All other buses are of 440V bus.
> There is a transformer of 11kV/440V  between bus 1 and 2.
> From bus 2 onwards are load bus.
> At some buses load is present at some buses no load is present.
> I know the values of R and X of line in ohm. 
> How to perform the load flow analysis of this system having two voltage 
> levels with transformer?
> How to proceed.
> 
>  I am able to perform the load flow analysis of the system from 440V and 
> downstream buses i.e. with one voltage level.
> I am facing the problem when I make bus 1 as slack bus with 11 kV.
> 
> When I have added the 11 kV line and performed the load flow total losses are 
> less than that of load flow when only 440V line and downstream loads are 
> present.
> 
> I am not getting what is wrong.
> Please help.
> Thank you.

Query in power flow analysis of radial distribution system with two voltage levels

[Irfan Mujawar]

I want to use the MATPOWER for load flow analysis of the practical radial
distribution system.
In the system two voltage levels are there.
First is 11 kV bus (Bus 1) which is slack bus.
All other buses are of 440V bus.
There is a transformer of 11kV/440V  between bus 1 and 2.
>From bus 2 onwards are load bus.
At some buses load is present at some buses no load is present.
I know the values of R and X of line in ohm.
How to perform the load flow analysis of this system having two voltage
levels with transformer?
How to proceed.

 I am able to perform the load flow analysis of the system from 440V and
downstream buses i.e. with one voltage level.
I am facing the problem when I make bus 1 as slack bus with 11 kV.

When I have added the 11 kV line and performed the load flow total losses
are less than that of load flow when only 440V line and downstream loads
are present.

I am not getting what is wrong.
Please help.
Thank you.

Re: Question regarding Matpower's continuation power flow

[Abhyankar, Shrirang G]

Hi Carlos,

Event:
   See MATPOWER manual section 5.5 for description of ‘events’ in MATPOWER. 
Basically, an event is a point on the continuation curve where some sort of 
limit or threshold is met. For example, a generator hitting its active/reactive 
power limit is an event. The full list of events MATPOWER supports is given in 
the manual. For each event located, MATPOWER saves information for the event 
(including a descriptive text) in its output struct (see results.cpf.event).

Rollback:
On detection of each event, MATPOWER locates or pinpoints the event using a 
‘rollback’ mechanism where the continuation step is reverted and the step-size 
reduced successively till the event is located, i.e., some tolerance is met for 
the event. MATPOWER prints whenever the step is reverted (or “rolled back”) 
during the event location process.

Look up Regular Falsi or False Position method on Google if you need additional 
details on event detection and location.

Hope this helps.

Shri
From: bounce-126939018-83436...@list.cornell.edu 
 on behalf of Carlos A. Castro 

Date: Monday, October 31, 2022 at 4:01 PM
To: MATPOWER-L@cornell.edu 
Subject: Question regarding Matpower's continuation power flow
Check twice before you click! This email originated from outside PNNL.

Dear friends

I have been running the continuation power flow for several networks.

In the case of "case2869pegase", I counted 92 rollbacks. However, "events" is a 
struct with dimension [1x98].

I was expecting that the dimension of "events" was [1x92], that is, the same as 
the number of rollbacks.

I would appreciate to hear from you regarding the relationship between 
rollbacks and events. What are those events specifically? Which events do not 
result in rollbacks?

Thanks a lot for your attention and help.

Regards,

Carlos A. Castro.

--
Prof. Carlos A. Castro
ccas...@ieee.org<mailto:ccas...@ieee.org>

Question regarding Matpower's continuation power flow

[Carlos A. Castro]

Dear friends

I have been running the continuation power flow for several networks.

In the case of "case2869pegase", I counted 92 rollbacks. However, "events"
is a struct with dimension [1x98].

I was expecting that the dimension of "events" was [1x92], that is, the
same as the number of rollbacks.

I would appreciate to hear from you regarding the relationship between
rollbacks and events. What are those events specifically? Which events do
not result in rollbacks?

Thanks a lot for your attention and help.

Regards,

Carlos A. Castro.

-- 
Prof. Carlos A. Castro
ccas...@ieee.org

Re:Re: Power flow calculation when changing the network topology

[Ziheng Yan]

Dear Ahmad,


   Thanks for your suggestions! 


   I've tried several power flow algorithms ('NR', 'GS', 'YSUM', etc.) 
referring to the manual, but the calculation all fails. 


   Considering your last advice, today I'm searching for explanations of power 
flow calculation failure. And I get that inappropriate network parameter 
setting can also lead to convergence failure for connected radiality networks. 
I reduce the default node loads by half and the power flow calculation 
succeeds. It turns out that the parameter setting needs to be further 
considered for reconfigured networks.


   (Reference: 
http://help.easypower.com/ezp/9.6/content/07_power_flow_analysis/Troubleshooting_Power_Flows_that_Fail_to_Solve.htm)


Best regards,


Yan











发件人：Ahmad Sadiq Abubakar 
发送日期：2022-05-01 12:01:10
收件人：MATPOWER discussion forum 
主题：Re: Power flow calculation when changing the network topology
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 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
>
>
>
>

Power flow calculation when changing the network topology

[Ziheng Yan]

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: Running Power flow with Voltage dependent load model

[Ray Daniel Zimmerman]

With MATPOWER 7 and earlier, unfortunately, there isn’t a really clean way to 
accomplish this. The way that comes to mind is to represent each load with a 
“fake” generator, and then add some user-defined nonlinear constraints (as 
described in Section 7.1.2 in the User’s Manual) that define the output of 
those “generators” as a function of the bus voltage.

In the development version of MATPOWER based on 
MP-Element, this will be easy to 
implement via a definition of a few new classes. But, the mechanisms for doing 
so are not yet completed and documented …

… but it’s coming …

 Ray



On Jan 10, 2022, at 4:22 AM, Arpit Srivastava M.Tech., Electrical Engineering, 
IIT(BHU) 
mailto:arpitsrivastava.ee...@itbhu.ac.in>> 
wrote:

Hello Matpower Users,
Please let me know How to run load flow with voltage dependent load models. In 
my case each bus load have to be modeled as:
Pload= Pl*(V)^pr
Qload= Ql*(V)^qr
where
Pload, Qload = voItage dependent real and reactive
power load.
Pl, Ql= real and reactive load at nominal voItage.
V= voItage magnitude
pr, qr= real and reactive power load co-efficients for
residential load model.
Assume pr= 0.72 and qr=2.96 for the present case.

Fwd: Running Power flow with Voltage dependent load model

[Arpit Srivastava M.Tech., Electrical Engineering, IIT(BHU)]

-- Forwarded message -
From: Arpit Srivastava M.Tech., Electrical Engineering, IIT(BHU) <
arpitsrivastava.ee...@itbhu.ac.in>
Date: Mon, Jan 10, 2022 at 3:52 PM
Subject: Running Power flow with Voltage dependent load model
To: 


Hello Matpower Users,
Please let me know How to run load flow with voltage dependent load models.
In my case each bus load have to be modeled as:
Pload= Pl*(V)^pr
Qload= Ql*(V)^qr
where
Pload, Qload = voItage dependent real and reactive
power load.
Pl, Ql= real and reactive load at nominal voItage.
V= voItage magnitude
pr, qr= real and reactive power load co-efficients for
residential load model.
Assume pr= 0.72 and qr=2.96 for the present case.

Running Power flow with Voltage dependent load model

[Arpit Srivastava M.Tech., Electrical Engineering, IIT(BHU)]

Hello Matpower Users,
Please let me know How to run load flow with voltage dependent load models.
In my case each bus load have to be modeled as:
Pload= Pl*(V)^pr
Qload= Ql*(V)^qr
where
Pload, Qload = voItage dependent real and reactive
power load.
Pl, Ql= real and reactive load at nominal voItage.
V= voItage magnitude
pr, qr= real and reactive power load co-efficients for
residential load model.
Assume pr= 0.72 and qr=2.96 for the present case.

Re: current of branch for DC power flow

[Ray Daniel Zimmerman]

MATPOWER does not include a function for computing the current from the branch 
power injections, but you can always get the complex current from the complex 
power and voltage.

I = (S / V)*

With the assumptions of the DC power flow (|V| ≈ 1, angle ≈ 0, Q negligible), 
the current is approximately equal to the power, so Sebaa is (almost) correct. 
That quantity actually 2x the current in the branch.

Ray


On Dec 7, 2021, at 10:44 PM, sebaa haddi 
mailto:sebaa...@yahoo.fr>> wrote:

Yes, the power injection (Sij)  in the sending bus - the power injection (Sji)  
in the reseiving bus

Le lundi 6 décembre 2021, 12:33:40 UTC+1, zahra nekudari 
mailto:znekud...@gmail.com>> a écrit :


Hi dears,
I want to know, there is any function for calculate current of any branch? I 
use DC power flow (rundcpf).

Re: current of branch for DC power flow

[sebaa haddi]

 Yes, the power injection (Sij)  in the sending bus - the power injection (Sji) 
 in the reseiving bus

Le lundi 6 décembre 2021, 12:33:40 UTC+1, zahra nekudari 
 a écrit :  
 
 Hi dears,I want to know, there is any function for calculate current of any 
branch? I use DC power flow (rundcpf).
  

current of branch for DC power flow

[zahra nekudari]

Hi dears,
I want to know, there is any function for calculate current of any branch?
I use DC power flow (rundcpf).

Re: DC power flow considering resistive losses

[Ray Daniel Zimmerman]

As you mention, MATPOWER does not currently include consideration of losses in 
the DC power flow or DC OPF. You could estimate the losses manually after the 
fact based on the resistances and the lines flows that result from the lossless 
DC power flow.

It would even be possible to run something like this iteratively, where the 
loss computed for each line is added as a load at the sending end of the line 
before re-solving.

… but you would have to write a few lines of MATLAB code to do this.

Ray


> On Sep 22, 2021, at 1:35 PM, harun.hoke...@metu.edu.tr wrote:
> 
> 
> Hi all,
> 
> 
> Is there any way to solve DC power flow problem considering line resistances?
> 
> The rundcpf and rundcopf commands solve the problem by ignoring all losses.
> 
> 
> Sincerely
> 
> 
> 
> 

DC power flow considering resistive losses

[harun . hokelek]

Hi all,


Is there any way to solve DC power flow problem considering line resistances?

The rundcpf and rundcopf commands solve the problem by ignoring all losses.


Sincerely

回复: How to calculate power flow of ac-dc hybrid distribution network?

[吴元熙]

Ok, Thank you very much, Ray.

从 Windows 版邮件发送

发件人: Ray Daniel Zimmerman
发送时间: 2021年8月28日 0:57
收件人: MATPOWER-L
主题: Re: How to calculate power flow of ac-dc hybrid distribution network?

You may want to check out the MATPOWER-FUBM fork of MATPOWER by Abraham 
Alvarez-Bustos. It has some AC-DC hybrid capabilities. I suggest you contact 
him directly about specifics.

   Ray



On Aug 26, 2021, at 9:20 PM, hhuw...@163.com wrote:

Hi,
I am wondering if Matpower can handle the power flow (or optimal power flow) of 
ac-dc hybrid distribution network? For example, I want to model a soft open 
point. Is there any way to model this?
Thank you.



 

Re: How to calculate power flow of ac-dc hybrid distribution network?

[Ray Daniel Zimmerman]

You may want to check out the 
MATPOWER-FUBM<https://github.com/AbrahamAlvarezB/matpower-fubm> fork of 
MATPOWER by Abraham Alvarez-Bustos. It has some AC-DC hybrid capabilities. I 
suggest you contact him directly about specifics.

   Ray


On Aug 26, 2021, at 9:20 PM, hhuw...@163.com<mailto:hhuw...@163.com> wrote:

Hi,
I am wondering if Matpower can handle the power flow (or optimal power flow) of 
ac-dc hybrid distribution network? For example, I want to model a soft open 
point. Is there any way to model this?
Thank you.

How to calculate power flow of ac-dc hybrid distribution network?

[hhuw...@163.com]

Hi,
I am wondering if Matpower can handle the power flow (or optimal power flow) of 
ac-dc hybrid distribution network? For example, I want to model a soft open 
point. Is there any way to model this?
Thank you.

Re: Ybus Construction: Parallel Branch Modelling for Power Flow

[Liang Chen]

Thanks very much!

From: bounce-125782784-86837...@list.cornell.edu 
 on behalf of Ray Daniel Zimmerman 

Sent: Tuesday, July 20, 2021 6:39 AM
To: MATPOWER-L 
Subject: Re: Ybus Construction: Parallel Branch Modelling for Power Flow

EXTERNAL EMAIL:
It is perfectly fine to replace parallel branches with a single equivalent 
branch. If done properly, it will result in an identical power flow solution.

   Ray


On Jul 16, 2021, at 1:22 PM, Liang Chen 
mailto:liangjie.c...@mail.utoronto.ca>> wrote:

Dear all,

I have a question regarding the construction of the admittance matrix 
(Equations 3.11-3.13 in the documentation, Modelling > Network Equations). I 
noticed that there are cases in which there are more than one branch from bus i 
to bus j, and cases where there are branches (i,j) and (j,i), i.e., both from i 
to j, and from j to i. For example, in case13659pegase.m, the branches (11001, 
9689) and (9689, 11001) both exist and have different impedance values.

My question is that, if we model the system as a simple directed graph for the 
power flow analysis (so the branch flow limits aren't important, and 
technically there cannot be multiple edges between any two nodes), could there 
be an issue if I "merge" the multiple parallel branches into a single 
equivalent branch? In addition, in the case where both branches (i,j) and (j,i) 
exist, if they both have unity transformer turns ratio, could there be a 
problem if I flip (j,i) to be (i,j) and proceed to merge the two into one 
single equivalent branch?

Thank you for your time and help!

Liangjie

Re: Ybus Construction: Parallel Branch Modelling for Power Flow

[Ray Daniel Zimmerman]

It is perfectly fine to replace parallel branches with a single equivalent 
branch. If done properly, it will result in an identical power flow solution.

   Ray


On Jul 16, 2021, at 1:22 PM, Liang Chen 
mailto:liangjie.c...@mail.utoronto.ca>> wrote:

Dear all,

I have a question regarding the construction of the admittance matrix 
(Equations 3.11-3.13 in the documentation, Modelling > Network Equations). I 
noticed that there are cases in which there are more than one branch from bus i 
to bus j, and cases where there are branches (i,j) and (j,i), i.e., both from i 
to j, and from j to i. For example, in case13659pegase.m, the branches (11001, 
9689) and (9689, 11001) both exist and have different impedance values.

My question is that, if we model the system as a simple directed graph for the 
power flow analysis (so the branch flow limits aren't important, and 
technically there cannot be multiple edges between any two nodes), could there 
be an issue if I "merge" the multiple parallel branches into a single 
equivalent branch? In addition, in the case where both branches (i,j) and (j,i) 
exist, if they both have unity transformer turns ratio, could there be a 
problem if I flip (j,i) to be (i,j) and proceed to merge the two into one 
single equivalent branch?

Thank you for your time and help!

Liangjie

Ybus Construction: Parallel Branch Modelling for Power Flow

[Liang Chen]

Dear all,

I have a question regarding the construction of the admittance matrix 
(Equations 3.11-3.13 in the documentation, Modelling > Network Equations). I 
noticed that there are cases in which there are more than one branch from bus i 
to bus j, and cases where there are branches (i,j) and (j,i), i.e., both from i 
to j, and from j to i. For example, in case13659pegase.m, the branches (11001, 
9689) and (9689, 11001) both exist and have different impedance values.

My question is that, if we model the system as a simple directed graph for the 
power flow analysis (so the branch flow limits aren't important, and 
technically there cannot be multiple edges between any two nodes), could there 
be an issue if I "merge" the multiple parallel branches into a single 
equivalent branch? In addition, in the case where both branches (i,j) and (j,i) 
exist, if they both have unity transformer turns ratio, could there be a 
problem if I flip (j,i) to be (i,j) and proceed to merge the two into one 
single equivalent branch?

Thank you for your time and help!

Liangjie

Re: voltage magnitude limits control in power flow

[Ray Daniel Zimmerman]

If you only need to control the voltage at generator buses, then you can do it 
simply via the generator voltage setpoint in mpc.gen(:, VG). Otherwise, you can 
always use an appropriately constrained OPF to solve the power flow problem.

 Ray


On Jun 29, 2021, at 10:07 PM, J C 
mailto:inglop...@gmail.com>> wrote:

Dear All,

Do you know if there exists the possibility of solving the power flow (NR) in 
matpower considering the voltage magnitude limits control?

Regards

Re: my power flow data is not converge by NR method

[Ray Daniel Zimmerman]

Have you tried the things mentioned in FAQ 
#5<https://matpower.org/doc/faq/#pfconvergence>?

Ray


On Jun 29, 2021, at 8:43 PM, Ari N 
mailto:ari.nrar...@gmail.com>> wrote:

hello everyone,

I need help. Can you check my power flow data?. The data on the attachment 
file. many thanks

voltage magnitude limits control in power flow

[J C]

Dear All,

Do you know if there exists the possibility of solving the power flow (NR)
in matpower considering the voltage magnitude limits control?

Regards

my power flow data is not converge by NR method

[Ari N]

hello everyone,

I need help. Can you check my power flow data?. The data on the attachment
file. many thanks
function [baseMVA, bus, gen, branch, area, gencost] = case161_01
% 08/25/93 UW ARCHIVE   100.0  1961 W IEEE 57 Bus Test Case
% The test system data was originally in IEEE Common Data Format.
% Its format has been converted to matpower format by cdf2matp.
 
baseMVA = 100.0; 
 
%bus type  Pd  Qd   Gs  Bsarea  Vm  Va  baseKV zone   
Vmax   Vmin
bus = [
1   3   0   0   0   0   1   1   0   20  
1   1.1 0.9
2   1   0.136   0.084   0   0   1   1   0   20  
1   1.1 0.9
3   1   5.673.508   0   0   1   1   0   20  
1   1.1 0.9
4   1   1.186   0.734   0   0   1   1   0   20  
1   1.1 0.9
5   1   4.395   2.719   0   0   1   1   0   20  
1   1.1 0.9
6   1   0.213   0.132   0   0   1   1   0   20  
1   1.1 0.9
7   1   0.561   0.347   0   0   1   1   0   20  
1   1.1 0.9
8   1   3.009   1.862   0   0   1   1   0   20  
1   1.1 0.9
9   1   1.084   0.671   0   0   1   1   0   20  
1   1.1 0.9
10  1   3.171   1.628   0   0   1   1   0   20  
1   1.1 0.9
11  1   3.253   2.013   0   0   1   1   0   20  
1   1.1 0.9
12  1   0.816   0.505   0   0   1   1   0   20  
1   1.1 0.9
13  1   2.441.510   0   1   1   0   20  
1   1.1 0.9
14  1   2.945   1.823   0   0   1   1   0   20  
1   1.1 0.9
15  2   0   0   0   0   1   1   0   20  
1   1.1 0.9
16  1   0.085   0.053   0   0   1   1   0   20  
1   1.1 0.9
17  1   5.326   3.296   0   0   1   1   0   20  
1   1.1 0.9
18  1   2.903   1.796   0   0   1   1   0   20  
1   1.1 0.9
19  1   2.441.510   0   1   1   0   20  
1   1.1 0.9
20  1   0.213   0.132   0   0   1   1   0   20  
1   1.1 0.9
21  1   0.268   0.166   0   0   1   1   0   20  
1   1.1 0.9
22  1   0.340.210   0   1   1   0   20  
1   1.1 0.9
23  1   0.647   0.4 0   0   1   1   0   20  
1   1.1 0.9
24  1   2.126   1.316   0   0   1   1   0   20  
1   1.1 0.9
25  1   1.063   0.658   0   0   1   1   0   20  
1   1.1 0.9
26  1   0.306   0.189   0   0   1   1   0   20  
1   1.1 0.9
27  1   1.632   1.010   0   1   1   0   20  
1   1.1 0.9
28  1   6.054   3.746   0   0   1   1   0   20  
1   1.1 0.9
29  2   12.381  7.660   0   1   1   0   20  
1   1.1 0.9
30  2   7.133   4.413   0   0   1   1   0   20  
1   1.1 0.9
31  1   8.437   5.221   0   0   1   1   0   20  
1   1.1 0.9
32  1   0.289   0.184   0   0   1   1   0   20  
1   1.1 0.9
33  1   3.693   2.286   0   0   1   1   0   20  
1   1.1 0.9
34  1   1.407   0.871   0   0   1   1   0   20  
1   1.1 0.9
35  1   12.874  7.967   0   0   1   1   0   20  
1   1.1 0.9
36  1   1.925   1.191   0   0   1   1   0   20  
1   1.1 0.9
37  1   2.554   1.581   0   0   1   1   0   20  
1   1.1 0.9
38  1   4.191   2.593   0   0   1   1   0   20  
1   1.1 0.9
39  1   0.965   0.597   0   0   1   1   0   20  
1   1.1 0.9
40  1   0   0   0   0   1   1   0   20  
1   1.1 0.9
41  2   39.038  24.156  0   0   1   1   0   20  
1   1.1 0.9
42  1   7.854   4.860   0   1   1   0   20  
1   1.1 0.9
43  1   5.3 3.280   0   1   1   0   20  
1   1.1 0.9
44  1   3.532   2.186   0   0   1   1   0   20  
1   1.1 0.9
45  1   0.842   0.521   0   0   1   1

Re: Continuous power flow question

[Abhyankar, Shrirang G]

Hi Simone,
   See the FAQ on power flow 
divergence<https://matpower.org/doc/faq/#pfconvergence>. It lists some useful 
tips to debug power flow divergence when using MATPOWER and how to run a 
continuation power flow to check if a power flow solution exists (point v).

Thanks,
Shri


From:  on behalf of Simone Fratton 

Reply-To: MATPOWER discussion forum 
Date: Tuesday, June 1, 2021 at 4:08 AM
To: "matpowe...@list.cornell.edu" 
Subject: Continuous power flow question

Check twice before you click! This email originated from outside PNNL.

Hi,
I would like to ask where I can find specific indications on the use of 
"continuous power flow" in Matpower? Maybe a video, an example Specifically 
I have a case (an electrical grid) for which Newton-Rapshon does not converge 
even if a solution exists and I thought of the "continuous power flow" to find 
this solution. I don't know if I can do it and also how to do it.
Thank you all and I apologize so much for the inconvenience.

Continuous power flow question

[Simone Fratton]

Hi,

I would like to ask where I can find specific indications on the use of
"continuous power flow" in Matpower? Maybe a video, an example
Specifically I have a case (an electrical grid) for which Newton-Rapshon
does not converge even if a solution exists and I thought of the
"continuous power flow" to find this solution. I don't know if I can do it
and also how to do it.

Thank you all and I apologize so much for the inconvenience.

Re:A question in calculating power flow

[yangyang]

The voltage magnitude of the slack bus and PV buses is controlled by the VG 
column in gen field, namely, column 6 of mpc.gen. Changing column VM in mpc.bus 
does not change them.



Best Regards,
Yang Yang


 




-- Original --
From:   
 "MATPOWER discussion forum"

<220205...@seu.edu.cn>;
Date: Thu, May 20, 2021 03:39 PM
To: "matpower-l"

Re: A question in calculating power flow

[Ilias Sarantakos]

Hi Yan,

Please try mpc.gen(6) = 1.03.

Kind regards,

Ilias

*Dr Ilias Sarantakos*

Research Associate

School of Engineering
Newcastle University

Στις Πέμ, 20 Μαΐ 2021 στις 8:42 π.μ., ο/η 颜子恒 <220205...@seu.edu.cn> έγραψε:

> Dears,
>
>Recently I have been confused by the voltage magnitude setting in a
> case model. Suppose in a distribution system like 'case33bw.m', like the
> way I did in revising the power demand I was trying to increase the
> voltage magnitude of node 1(Reference node) by implementing 
> mpc.bus(1,VM)=1.0025.
> After running runpf(mpc), the result shows that it does not work, the
> voltage magnitude of node 1 still converge to 1. Since the voltage
> magnitude of a reference node is supposed to be static during power flow
> calculation, I wanna ask you how could I revise the voltage magnitude of
> a reference node in a case file?
>
>Thank you in advance, early reply is appreciated.
>
>
> Regards,
>
> Yan
>

A question in calculating power flow

[颜子恒]

Dears,

   Recently I have been confused by the voltage magnitude setting in a case 
model. Suppose in a distribution system like 'case33bw.m', like the way I did 
in revising the power demand I was trying to increase the voltage magnitude of 
node 1(Reference node) by implementing mpc.bus(1,VM)=1.0025. After running 
runpf(mpc), the result shows that it does not work, the voltage magnitude of 
node 1 still converge to 1. Since the voltage magnitude of a reference node is 
supposed to be static during power flow calculation,I wanna ask you how could I 
revise the voltage magnitude of a reference node in a case file?

   Thank you in advance, early reply is appreciated.





Regards,

Yan

Power flow starting points

[Abdelrahman Aldik]

Hello

I would like to ask if Matpower allows for choosing a starting point for
solving the power flow problem other than the flat start? If possible, how
can it be done?

Thanks

-- 




*Abdelrahman AldikPhD Candidate Department of Electrical and Computer
Engineering and Centre of Urban Energy Ryerson University CUI-030, 44
Gerrard Street East, Toronto, ON, Canada*
*Email: aal...@ryerson.ca *

Re: Implementation of power flow using fmincon

[Ray Daniel Zimmerman]

Hi Yang,

Unfortunately, I don’t have time at the moment to look at your code, but what 
you describe should work, if you are able to provide the right functions and 
derivatives (not sure how well the methods that don’t require derivatives work).

I actually implemented a wrapper around runopf() to use it to solve the power 
flow problem. So if you’re using FMINCON as the OPF solver it should be 
something similar to your second approach, though implemented differently 
(probably more variables and constraints). See the attached file called 
runpfbyopf.m.

   Ray



On Mar 6, 2021, at 10:45 PM, yangyang 
<980182...@qq.com<mailto:980182...@qq.com>> wrote:

Dear Ray,

  Recently I am doing research on implementing of power flow (note: NOT OPTIMAL 
POWER FLOW) using matlab function fmincon(). I have two kinds of implementation:
  One is to take the normF in newtonpf() as the objective for fmincon(), since 
the process of newtonpf() is just the process of minimizing normF until it is 
smaller than tolerance.
  The second implementation is to use the equality constraints of power 
balance, that is,
F = V .* conj(Ybus * V) - Sbus;
where V is the complex voltage vector and Sbus is generated using makeSbus(), 
and then the equaltiy and inequaltiy constranits are:
ceq = [real(F(pv; pq));  imag(F(pq))];
cineq = [];
  There are no inequality constranits for the 9th argin of fmincon (nnlcon) 
since the power flow equations dont need inequaltiy constraints. For the 
objective of fmincon(), a useless function handle that doesnt change with input 
at all is used, since the equality constraints are used, no objective is needed 
and nothing is optimized, so the only need is to keep the constraints. The 
objective can be like:
@(x) sum(0 * x)
  Theretically, I think this is a feasible way, but for the 1st implementaion, 
the fmincon() always fail to find a good normF, and such ouptput will be 
reported:
Solver stopped prematurely.

fmincon stopped because it exceeded the function evaluation limit,
options.MaxFunctionEvaluations = 3.00e+03.
and the fbest is always around 0.1 to 0.7, which is much worse than the 
tolerance (around 1e-5 to 1e-8).
  For the second implementation, the same report will appear, and the results 
are also not very good. I am wondering if there are suitable ways to set up 
input arguments for the fmincon() function to calculate a accurate solution 
like runpf()? My codes are as attached. Function runpf_fmincon can be 
compatible with any mpc struct. The first implementation is fminconpf and the 
2nd fminconpf2; change the function name in line 177 in runpf_fmincon from 
fminconpf to fminconpf2, to test the 2nd implementation. Thank you for your 
patience and time.

Best Regards,
Yang Yang






runpfbyopf.m
Description: runpfbyopf.m

Implementation of power flow using fmincon

[yangyang]

Dear Ray,


  Recently I am doing research on implementing of power flow (note: NOT 
OPTIMAL POWER FLOW) using matlab function fmincon(). I have two kinds of 
implementation: 
  One is to take the normF in newtonpf() as the objective for fmincon(), 
since the process of newtonpf() is just the process of minimizing normF until 
it is smaller than tolerance. 
  The second implementation is to use the equality constraints of power 
balance, that is, 
F = V .* conj(Ybus * V) - Sbus;
where V is the complex voltage vector and Sbus is generated using makeSbus(), 
and then the equaltiy and inequaltiy constranits are:
ceq = [real(F(pv; pq));  imag(F(pq))];
cineq = [];
  There are no inequality constranits for the 9th argin of fmincon 
(nnlcon) since the power flow equations dont need inequaltiy constraints. For 
the objective of fmincon(), a useless function handle that doesnt change with 
input at all is used, since the equality constraints are used, no objective is 
needed and nothing is optimized, so the only need is to keep the constraints. 
The objective can be like: 
@(x) sum(0 * x)
  Theretically, I think this is a feasible way, but for the 1st 
implementaion, the fmincon() always fail to find a good normF, and such ouptput 
will be reported:
Solver stopped prematurely.


fmincon stopped because it exceeded the function evaluation limit,
options.MaxFunctionEvaluations = 3.00e+03.

and the fbest is always around 0.1 to 0.7, which is much worse than the 
tolerance (around 1e-5 to 1e-8). 
  For the second implementation, the same report will appear, and the 
results are also not very good. I am wondering if there are suitable ways to 
set up input arguments for the fmincon() function to calculate a accurate 
solution like runpf()? My codes are as attached. Function runpf_fmincon can be 
compatible with any mpc struct. The first implementation is fminconpf and the 
2nd fminconpf2; change the function name in line 177 in runpf_fmincon from 
fminconpf to fminconpf2, to test the 2nd implementation. Thank you for your 
patience and time.

Best Regards,
Yang Yang


 


runpf_fmincon.m
Description: Binary data


fminconpf2.m
Description: Binary data


fminconpf.m
Description: Binary data

Re: Modelling and Power Flow Validation

[Ray Daniel Zimmerman]

Hi Tobias,

For your first question, please see the relevant derivation in Section 3.7 of 
the User’s Manual<https://matpower.org/docs/MATPOWER-manual-7.1.pdf>. This 
describes the formulation used by MATPOWER. I suppose it is possible that some 
DC power flow implementations also include the approximation that the tap ratio 
is 1. Off the top of my head, I’m can’t really comment on the impact of 
including (or not) that approximation.

Regarding the second question, getting an exact match between MATPOWER and the 
commercial software would require both correct parameters for MATPOWER and an 
identical model. It seems likely that the commercial software could be using a 
more sophisticated model that does include the iron loss current and 
magnetizing current, as mentioned by Carlos in the message you referenced. If 
that is the case, I suppose his suggestions could possibly be used to adjust 
some parameters (e.g. add shunts) to more closely approximate the commercial 
software solution.

On the other hand, given the state of the work on a new network and modeling 
layer for MATPOWER, called MP-Element<https://github.com/MATPOWER/mp-element/> 
(made public only days ago), now is probably a good time to call for help to 
work on improved transformer model implementations for MATPOWER.

Ray




On Oct 30, 2020, at 6:02 AM, Hoffmann, Tobias 
mailto:tobias4.hoffm...@tu-dortmund.de>> wrote:

Dear all,

in my work I’m trying to validate a module that creates a mpc with required 
grid information (buses, topology information, loads, …). Therefore I have two 
questions related to the correct modelling of the MATPOWER case file.


1)  After some adjustments of the model, I receive very accurate results 
for the DC power flow in matpower compared with a commercial powerflow tool. 
The decisive setting was the neglection of the parameters in the TAP column for 
the transformers. The only place where the TAP column is considered for the DC 
power flow is inside the function makeBdc below (line 64/65).

[Bbus, Bf, Pbusinj, Pfinj] = makeBdc(baseMVA, bus, branch
…
stat = branch(:, BR_STATUS);"
OutmailID: 125086863, List: 'matpower-l', MemberID: 82861091
SCRIPT: "ones at in-service branches
 b = stat ./ branch(:, BR_X);"
TCL MERGE ERROR ( 10/30/2020 10:39:49 ): "invalid command name "ones" series 
susceptance
tap = ones(nl, 1);  "
OutmailID: 125086863, List: 'matpower-l', MemberID: 82861091
SCRIPT: "default tap ratio = 1
 i = find(branch(:, TAP));"
TCL MERGE ERROR ( 10/30/2020 10:39:49 ): "invalid command name "default" 
indices of non-zero tap ratios
tap(i) = branch(i, TAP);"
OutmailID: 125086863, List: 'matpower-l', MemberID: 82861091
SCRIPT: "assign non-zero tap ratios
 b = b ./ tap;
 
_
 
 After I received the results, I’m still trying to understand the influence of 
the column TAP (the transformer off nominal turns ratio). According to my 
actual understanding of the DC power flow only the reactance has an influence 
on the resulting flows.
 
 May someone be so kind to explain me the consideration of the TAP column in 
the makeBdc-function. I already found the old post here but would like to 
understand it even better 
(https://www.mail-archive.com/matpower-l@cornell.edu/msg00320.html).
 
 
 2)  My second question is related to a proper validation of the AC-power 
flow. Here I have an issue with the modelling of transformers as I get 
different results between MATPOWER compared to a commercial powerflow tool. As 
I describe above the result for the DC-power flow are already quite accurate. 
Below I show the same input data for the transformer. It is a 2-winding 
transformer connecting two different voltage levels without any shifting. I’m 
trying to validate the AC-power flow in a small test grid with five nodes and 
the slack at “NODE2_21”.
 
 
 - 2 WINDING TRANSFORMER BLOCK -
 
_1_2_3_4_5_6_7_8_9
 Node 1  |Node 2  |O|S|U1   |U2   |Sn   |R(Ohm)|X(Ohm)|B(uS)   |G(uS) |I(A)  
|Element Name|
 
 ##T
 NODE5_81 NODE2_21 1 0 347.0 242.0 240.0 1.1200 44.100 -28. 1.400 
TR-1
 
 To calculate the right values for the branch matrix I use the following values 
from the depending transformer:
 
 - baseKV_from = 347 kV
 
 - baseMVA = 100 MVA
 
 - zbase_from = basekV_from^2 / baseMVA
 
 - BR_R = 1.12 (Ohm) / zbase_from
 
 - BR_X = 44.1 (Ohm) / zbase_from
 
 - BR_B = -28 (uS) * 10^-6 * zbase_from
 My results for the branch matrix are
 
 - BR_R = 0,00093
 
 - BR_X = 0,03662
 
 - BR_B = -0,03371

Modelling and Power Flow Validation

[Hoffmann, Tobias]

Dear all,

in my work I'm trying to validate a module that creates a mpc with required 
grid information (buses, topology information, loads, ...). Therefore I have 
two questions related to the correct modelling of the MATPOWER case file.


1)  After some adjustments of the model, I receive very accurate results 
for the DC power flow in matpower compared with a commercial powerflow tool. 
The decisive setting was the neglection of the parameters in the TAP column for 
the transformers. The only place where the TAP column is considered for the DC 
power flow is inside the function makeBdc below (line 64/65).

[Bbus, Bf, Pbusinj, Pfinj] = makeBdc(baseMVA, bus, branch
...
stat = branch(:, BR_STATUS);%% ones at in-service branches
b = stat ./ branch(:, BR_X);%% series susceptance
tap = ones(nl, 1);  %% default tap ratio = 1
i = find(branch(:, TAP));   %% indices of non-zero tap 
ratios
tap(i) = branch(i, TAP);%% assign non-zero tap ratios
b = b ./ tap;
_

After I received the results, I'm still trying to understand the influence of 
the column TAP (the transformer off nominal turns ratio). According to my 
actual understanding of the DC power flow only the reactance has an influence 
on the resulting flows.

May someone be so kind to explain me the consideration of the TAP column in the 
makeBdc-function. I already found the old post here but would like to 
understand it even better 
(https://www.mail-archive.com/matpower-l@cornell.edu/msg00320.html).


2)  My second question is related to a proper validation of the AC-power 
flow. Here I have an issue with the modelling of transformers as I get 
different results between MATPOWER compared to a commercial powerflow tool. As 
I describe above the result for the DC-power flow are already quite accurate. 
Below I show the same input data for the transformer. It is a 2-winding 
transformer connecting two different voltage levels without any shifting. I'm 
trying to validate the AC-power flow in a small test grid with five nodes and 
the slack at "NODE2_21".


- 2 WINDING TRANSFORMER BLOCK -
_1_2_3_4_5_6_7_8_9
Node 1  |Node 2  |O|S|U1   |U2   |Sn   |R(Ohm)|X(Ohm)|B(uS)   |G(uS) |I(A)  
|Element Name|

##T
NODE5_81 NODE2_21 1 0 347.0 242.0 240.0 1.1200 44.100 -28. 1.400 
TR-1

To calculate the right values for the branch matrix I use the following values 
from the depending transformer:

- baseKV_from = 347 kV

- baseMVA = 100 MVA

- zbase_from = basekV_from^2 / baseMVA

- BR_R = 1.12 (Ohm) / zbase_from

- BR_X = 44.1 (Ohm) / zbase_from

- BR_B = -28 (uS) * 10^-6 * zbase_from
My results for the branch matrix are

- BR_R = 0,00093

- BR_X = 0,03662

- BR_B = -0,03371
Without modelling a load/generation at node "NODE5_81" I receive quite 
different results in voltage magnitude/angle.

- MAPTOWER

o   VM = 1,04480948; VA= 0,000897843

- Commercial powerflow tool

o   VM = 0,998756671; VA = -0,000364748875

I suppose that it has do something with the modelling of the transformer losses 
in matpower. But I don't have a clue how to get more accurate results. I also 
tried the approach to model the losses as suggested here 
(https://www.mail-archive.com/matpower-l@cornell.edu/msg02291.html). If someone 
can give me a hint where to look at, I would be very thankful!

Thank you very much. With kind regards,
Tobias Hoffmann



Wichtiger Hinweis: Die Information in dieser E-Mail ist vertraulich. Sie ist 
ausschlie?lich f?r den Adressaten bestimmt. Sollten Sie nicht der f?r diese 
E-Mail bestimmte Adressat sein, unterrichten Sie bitte den Absender und 
vernichten Sie diese Mail. Vielen Dank.
Unbeschadet der Korrespondenz per E-Mail, sind unsere Erkl?rungen 
ausschlie?lich final rechtsverbindlich, wenn sie in herk?mmlicher Schriftform 
(mit eigenh?ndiger Unterschrift) oder durch ?bermittlung eines solchen 
Schriftst?cks per Telefax erfolgen.

Important note: The information included in this e-mail is confidential. It is 
solely intended for the recipient. If you are not the intended recipient of 
this e-mail please contact the sender and delete this message. Thank you. 
Without prejudice of e-mail correspondence, our statements are only legally 
binding when they are made in the conventional written form (with personal 
signature) or when such documents are sent by fax.

load during CPF (was Re: Optimal power flow with DG connected)

[Ray Daniel Zimmerman]

The load at each step is a function of lambda, the continuation parameter, 
which is used to interpolate between the base case load (lambda = 0) and the 
target case load (lambda = 1). So you can use the following to find the load at 
the current value of lambda …

Pd_current = Pd_base * (1 - lambda) + Pd_target * lambda

… where Pd_base is taken from the PD column of mpc_base and Pd_target from the 
PD column of mpc_target.

The target and base cases and current value of lambda are available to CPF 
callback functions, if you really need it during the process. But the 
step-by-step history of lambda is also available after the CPF run is complete 
in results.cpf.lam.

Hope this helps,

Ray



On Oct 4, 2020, at 12:45 AM, 走下去 <1411608...@qq.com<mailto:1411608...@qq.com>> 
wrote:

Hi,everyone, I want to ask a question, which is that when I run the cpf 
function in MATPOWER, how can I get the Pload during the process?


-- 原始邮件 --
发件人: "MATPOWER discussion forum" 
mailto:mirishtha...@gmail.com>>;
发送时间: 2020年9月17日(星期四) 晚上9:29
收件人: "MATPOWER discussion 
forum"mailto:matpowe...@list.cornell.edu>>;
主题: Re: Optimal power flow with DG connected

Hi,
It's the file or casefile or M-file/MAT-file on which you are performing opf 
operations for analysis.
e.g. runopf(case9) here case9 is the file he asked for.
Thanks
Mirish

On Wed, Sep 16, 2020 at 6:43 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Which file do I need to send you?
please specify it.

Regards
Surbhi Aggarwal


On Tue, Sep 15, 2020 at 7:03 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
Looks like the Jacobian is singular. Feel free to send me the case (off-list) 
and I’ll have a look.

Ray


On Sep 14, 2020, at 11:35 PM, Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:

Even after doing everything, this error prompts out.
Please help me out with this issue.

Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)


Regards
Surbhi Aggarwal


On Mon, Sep 14, 2020 at 7:31 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
You would have to confirm the cause of the non-convergence before drawing any 
conclusions. You may find FAQ #5<https://matpower.org/doc/faq/#pfconvergence> 
helpful.

   Ray

On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:

Hello
If the system does not converge within 10 iterations, can we say that it is one 
of the most severely affected lines in contingency studies?
Or any other explanation for this non-convergence?
Regards
Surbhi Aggarwal


On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello
Thank you all for your help and I'll definitely look out for the solutions.
Thank you so much
Regards
Surbhi Aggarwal


On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
Hi Surbhi,

It looks like you were using the default Newton power flow. To increase the 
number of iterations, you can increase the pf.nr.max_it option. However, this 
is rarely necessary. If the Newton method is going to converge, it usually does 
so in less than the default 10 iterations. If it is not converging within 10 
iterations, it is likely that the problem has no solution or that you need a 
better starting point.

   Ray


On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

First of all why do you want to increase the number of steps/ iterations in the 
calculation? Is there any specific need? Actually the number of iterations 
depends on the power flow optimization tolerance. Maybe you can focus on the 
mpoption function and read it carefully. You can update something like here:
mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
I'm not 100 % sure about it but it may help you. Thanks.

Kind regards
Mirish

On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello Everyone,
I tried your suggestions and it somehow helped me.
Now my doubt is " If I want to increase my number of iterations, what steps I 
have to do"?
Please help me out
Regards
Surbhi Aggarwal


On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
I also suspect that the network becomes disconnected by removing certain lines. 
You can check the connectivity using 
case_info()<https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or 
find_islands()<https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
 If there are islands, then each island needs to have its own reference bus, 
and the local generation needs to be able to meet the local load in each island.

Ray


On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
mailto:mirish

?????? Optimal power flow with DG connected

[??????]

Hi,everyone, I want to ask a question, which is that when I run the cpf 
function in MATPOWER, how can I get the Pload during the process?




--  --
??: 
   "MATPOWER discussion forum"  
  

Re: Optimal power flow with DG connected

[Mirish Thakur]

Hi,
It's the file or casefile or M-file/MAT-file on which you are performing
opf operations for analysis.
e.g. runopf(case9) here *case9 *is the file he asked for.
Thanks
Mirish

On Wed, Sep 16, 2020 at 6:43 AM Surbhi Aggarwal 
wrote:

> Which file do I need to send you?
> please specify it.
>
> Regards
> Surbhi Aggarwal
>
>
> On Tue, Sep 15, 2020 at 7:03 PM Ray Daniel Zimmerman 
> wrote:
>
>> Looks like the Jacobian is singular. Feel free to send me the case
>> (off-list) and I’ll have a look.
>>
>> Ray
>>
>>
>> On Sep 14, 2020, at 11:35 PM, Surbhi Aggarwal 
>> wrote:
>>
>> Even after doing everything, this error prompts out.
>> Please help me out with this issue.
>>
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>>
>>
>> Regards
>> Surbhi Aggarwal
>>
>>
>> On Mon, Sep 14, 2020 at 7:31 PM Ray Daniel Zimmerman 
>> wrote:
>>
>>> You would have to confirm the cause of the non-convergence before
>>> drawing any conclusions. You may find FAQ #5
>>> <https://matpower.org/doc/faq/#pfconvergence> helpful.
>>>
>>>Ray
>>>
>>> On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
>>> wrote:
>>>
>>> Hello
>>> If the system does not converge within 10 iterations, can we say that it
>>> is one of the most severely affected lines in contingency studies?
>>> Or any other explanation for this non-convergence?
>>> Regards
>>> Surbhi Aggarwal
>>>
>>>
>>> On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal <
>>> surbhiaggarwa...@gmail.com> wrote:
>>>
>>>> Hello
>>>> Thank you all for your help and I'll definitely look out for the
>>>> solutions.
>>>> Thank you so much
>>>> Regards
>>>> Surbhi Aggarwal
>>>>
>>>>
>>>> On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
>>>> wrote:
>>>>
>>>>> Hi Surbhi,
>>>>>
>>>>> It looks like you were using the default Newton power flow. To
>>>>> increase the number of iterations, you can increase the pf.nr.max_it
>>>>> option. However, this is rarely necessary. If the Newton method is going 
>>>>> to
>>>>> converge, it usually does so in less than the default 10 iterations. If it
>>>>> is not converging within 10 iterations, it is likely that the problem has
>>>>> no solution or that you need a better starting point.
>>>>>
>>>>>Ray
>>>>>
>>>>>
>>>>> On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
>>>>> wrote:
>>>>>
>>>>> Hi Surbhi,
>>>>>
>>>>> First of all why do you want to increase the number of steps/
>>>>> iterations in the calculation? Is there any specific need? Actually the
>>>>> number of iterations depends on the power flow optimization tolerance.
>>>>> Maybe you can focus on the mpoption function and read it carefully. You 
>>>>> can
>>>>> update something like here:
>>>>> mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
>>>>> I'm not 100 % sure about it but it may help you. Thanks.
>>>>>
>>>>> Kind regards
>>>>> Mirish
>>>>>
>>>>> On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal <
>>>>> surbhiaggarwa...@gmail.com> wrote:
>>>>>
>>>>>> Hello Everyone,
>>>>>> I tried your suggestions and it somehow helped me.
>>>>>> Now my doubt is " If I want to increase my number of iterations, what
>>>>>> steps I have to do"?
>>>>>> Please help me out
>>>>>> Regards
>>>>>> Surbhi Aggarwal
>>>>>>
>>>>>>
>>>>>> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
>>>>>> wrote:
>>>>>>
>>>>>>> I also suspect that the network becomes disconnected by removing
>>>>>>> certain lines. You can check the connectivity using case_info()
>>>>>>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>>>>>>> find_islands()
>>>>>>> <https://matpowe

Re: Optimal power flow with DG connected

[Surbhi Aggarwal]

Which file do I need to send you?
please specify it.

Regards
Surbhi Aggarwal


On Tue, Sep 15, 2020 at 7:03 PM Ray Daniel Zimmerman 
wrote:

> Looks like the Jacobian is singular. Feel free to send me the case
> (off-list) and I’ll have a look.
>
> Ray
>
>
> On Sep 14, 2020, at 11:35 PM, Surbhi Aggarwal 
> wrote:
>
> Even after doing everything, this error prompts out.
> Please help me out with this issue.
>
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
>
>
> Regards
> Surbhi Aggarwal
>
>
> On Mon, Sep 14, 2020 at 7:31 PM Ray Daniel Zimmerman 
> wrote:
>
>> You would have to confirm the cause of the non-convergence before drawing
>> any conclusions. You may find FAQ #5
>> <https://matpower.org/doc/faq/#pfconvergence> helpful.
>>
>>Ray
>>
>> On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
>> wrote:
>>
>> Hello
>> If the system does not converge within 10 iterations, can we say that it
>> is one of the most severely affected lines in contingency studies?
>> Or any other explanation for this non-convergence?
>> Regards
>> Surbhi Aggarwal
>>
>>
>> On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal <
>> surbhiaggarwa...@gmail.com> wrote:
>>
>>> Hello
>>> Thank you all for your help and I'll definitely look out for the
>>> solutions.
>>> Thank you so much
>>> Regards
>>> Surbhi Aggarwal
>>>
>>>
>>> On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
>>> wrote:
>>>
>>>> Hi Surbhi,
>>>>
>>>> It looks like you were using the default Newton power flow. To increase
>>>> the number of iterations, you can increase the pf.nr.max_it option.
>>>> However, this is rarely necessary. If the Newton method is going to
>>>> converge, it usually does so in less than the default 10 iterations. If it
>>>> is not converging within 10 iterations, it is likely that the problem has
>>>> no solution or that you need a better starting point.
>>>>
>>>>Ray
>>>>
>>>>
>>>> On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
>>>> wrote:
>>>>
>>>> Hi Surbhi,
>>>>
>>>> First of all why do you want to increase the number of steps/
>>>> iterations in the calculation? Is there any specific need? Actually the
>>>> number of iterations depends on the power flow optimization tolerance.
>>>> Maybe you can focus on the mpoption function and read it carefully. You can
>>>> update something like here:
>>>> mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
>>>> I'm not 100 % sure about it but it may help you. Thanks.
>>>>
>>>> Kind regards
>>>> Mirish
>>>>
>>>> On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal <
>>>> surbhiaggarwa...@gmail.com> wrote:
>>>>
>>>>> Hello Everyone,
>>>>> I tried your suggestions and it somehow helped me.
>>>>> Now my doubt is " If I want to increase my number of iterations, what
>>>>> steps I have to do"?
>>>>> Please help me out
>>>>> Regards
>>>>> Surbhi Aggarwal
>>>>>
>>>>>
>>>>> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
>>>>> wrote:
>>>>>
>>>>>> I also suspect that the network becomes disconnected by removing
>>>>>> certain lines. You can check the connectivity using case_info()
>>>>>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>>>>>> find_islands()
>>>>>> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
>>>>>> If there are islands, then each island needs to have its own reference 
>>>>>> bus,
>>>>>> and the local generation needs to be able to meet the local load in each
>>>>>> island.
>>>>>>
>>>>>> Ray
>>>>>>
>>>>>>
>>>>>> On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
>>>>>> wrote:
>>>>>>
>>>>>> Hi Surbhi,
>>>>>>
>>>>>> Could you please check the continuity of the system before running
>>>>>> opf? I mean to say if

Re: Optimal power flow with DG connected

[Ray Daniel Zimmerman]

Looks like the Jacobian is singular. Feel free to send me the case (off-list) 
and I’ll have a look.

Ray


On Sep 14, 2020, at 11:35 PM, Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:

Even after doing everything, this error prompts out.
Please help me out with this issue.

Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)


Regards
Surbhi Aggarwal


On Mon, Sep 14, 2020 at 7:31 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
You would have to confirm the cause of the non-convergence before drawing any 
conclusions. You may find FAQ #5<https://matpower.org/doc/faq/#pfconvergence> 
helpful.

   Ray

On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:

Hello
If the system does not converge within 10 iterations, can we say that it is one 
of the most severely affected lines in contingency studies?
Or any other explanation for this non-convergence?
Regards
Surbhi Aggarwal


On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello
Thank you all for your help and I'll definitely look out for the solutions.
Thank you so much
Regards
Surbhi Aggarwal


On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
Hi Surbhi,

It looks like you were using the default Newton power flow. To increase the 
number of iterations, you can increase the pf.nr.max_it option. However, this 
is rarely necessary. If the Newton method is going to converge, it usually does 
so in less than the default 10 iterations. If it is not converging within 10 
iterations, it is likely that the problem has no solution or that you need a 
better starting point.

   Ray


On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

First of all why do you want to increase the number of steps/ iterations in the 
calculation? Is there any specific need? Actually the number of iterations 
depends on the power flow optimization tolerance. Maybe you can focus on the 
mpoption function and read it carefully. You can update something like here:
mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
I'm not 100 % sure about it but it may help you. Thanks.

Kind regards
Mirish

On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello Everyone,
I tried your suggestions and it somehow helped me.
Now my doubt is " If I want to increase my number of iterations, what steps I 
have to do"?
Please help me out
Regards
Surbhi Aggarwal


On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
I also suspect that the network becomes disconnected by removing certain lines. 
You can check the connectivity using 
case_info()<https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or 
find_islands()<https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
 If there are islands, then each island needs to have its own reference bus, 
and the local generation needs to be able to meet the local load in each island.

Ray


On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

Could you please check the continuity of the system before running opf? I mean 
to say if you run opf for (n-1) criteria the system should be still well 
connected. There shouldn't be any island within the system itself. Perhaps you 
can test your model by removing any one parallel line (which you can observe 
later for analysis) and run the model under (n-1) criteria. This could be the 
easiest way to test the model. Thank you.

Kind regards
Mirish


On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Dear All,
I am working on optimal power flow to find the contingency (N-1) situation of 
the system. For some of the line outage, certain output pops out

MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In r

Re: Optimal power flow with DG connected

[Surbhi Aggarwal]

Even after doing everything, this error prompts out.
Please help me out with this issue.

Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)


Regards
Surbhi Aggarwal


On Mon, Sep 14, 2020 at 7:31 PM Ray Daniel Zimmerman 
wrote:

> You would have to confirm the cause of the non-convergence before drawing
> any conclusions. You may find FAQ #5
> <https://matpower.org/doc/faq/#pfconvergence> helpful.
>
>Ray
>
> On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
> wrote:
>
> Hello
> If the system does not converge within 10 iterations, can we say that it
> is one of the most severely affected lines in contingency studies?
> Or any other explanation for this non-convergence?
> Regards
> Surbhi Aggarwal
>
>
> On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal <
> surbhiaggarwa...@gmail.com> wrote:
>
>> Hello
>> Thank you all for your help and I'll definitely look out for the
>> solutions.
>> Thank you so much
>> Regards
>> Surbhi Aggarwal
>>
>>
>> On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
>> wrote:
>>
>>> Hi Surbhi,
>>>
>>> It looks like you were using the default Newton power flow. To increase
>>> the number of iterations, you can increase the pf.nr.max_it option.
>>> However, this is rarely necessary. If the Newton method is going to
>>> converge, it usually does so in less than the default 10 iterations. If it
>>> is not converging within 10 iterations, it is likely that the problem has
>>> no solution or that you need a better starting point.
>>>
>>>Ray
>>>
>>>
>>> On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
>>> wrote:
>>>
>>> Hi Surbhi,
>>>
>>> First of all why do you want to increase the number of steps/ iterations
>>> in the calculation? Is there any specific need? Actually the number of
>>> iterations depends on the power flow optimization tolerance. Maybe you can
>>> focus on the mpoption function and read it carefully. You can update
>>> something like here:
>>> mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
>>> I'm not 100 % sure about it but it may help you. Thanks.
>>>
>>> Kind regards
>>> Mirish
>>>
>>> On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal <
>>> surbhiaggarwa...@gmail.com> wrote:
>>>
>>>> Hello Everyone,
>>>> I tried your suggestions and it somehow helped me.
>>>> Now my doubt is " If I want to increase my number of iterations, what
>>>> steps I have to do"?
>>>> Please help me out
>>>> Regards
>>>> Surbhi Aggarwal
>>>>
>>>>
>>>> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
>>>> wrote:
>>>>
>>>>> I also suspect that the network becomes disconnected by removing
>>>>> certain lines. You can check the connectivity using case_info()
>>>>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>>>>> find_islands()
>>>>> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>. If
>>>>> there are islands, then each island needs to have its own reference bus,
>>>>> and the local generation needs to be able to meet the local load in each
>>>>> island.
>>>>>
>>>>> Ray
>>>>>
>>>>>
>>>>> On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
>>>>> wrote:
>>>>>
>>>>> Hi Surbhi,
>>>>>
>>>>> Could you please check the continuity of the system before running
>>>>> opf? I mean to say if you run opf for (n-1) criteria the system should be
>>>>> still well connected. There shouldn't be any island within the system
>>>>> itself. Perhaps you can test your model by removing any one parallel line
>>>>> (which you can observe later for analysis) and run the model under (n-1)
>>>>> criteria. This could be the easiest way to test the model. Thank you.
>>>>>
>>>>> Kind regards
>>>>> Mirish
>>>>>
>>>>>
>>>>> On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal <
>>>>> surbhiaggarwa...@gmail.com> wrote:
>>>>>
>>>>>> Dear All,
>>>>>> I am working on optimal power flow to find the c

Re: Optimal power flow with DG connected

[Ray Daniel Zimmerman]

You would have to confirm the cause of the non-convergence before drawing any 
conclusions. You may find FAQ #5<https://matpower.org/doc/faq/#pfconvergence> 
helpful.

   Ray

On Sep 12, 2020, at 6:43 AM, Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:

Hello
If the system does not converge within 10 iterations, can we say that it is one 
of the most severely affected lines in contingency studies?
Or any other explanation for this non-convergence?
Regards
Surbhi Aggarwal


On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello
Thank you all for your help and I'll definitely look out for the solutions.
Thank you so much
Regards
Surbhi Aggarwal


On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
Hi Surbhi,

It looks like you were using the default Newton power flow. To increase the 
number of iterations, you can increase the pf.nr.max_it option. However, this 
is rarely necessary. If the Newton method is going to converge, it usually does 
so in less than the default 10 iterations. If it is not converging within 10 
iterations, it is likely that the problem has no solution or that you need a 
better starting point.

   Ray


On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

First of all why do you want to increase the number of steps/ iterations in the 
calculation? Is there any specific need? Actually the number of iterations 
depends on the power flow optimization tolerance. Maybe you can focus on the 
mpoption function and read it carefully. You can update something like here:
mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
I'm not 100 % sure about it but it may help you. Thanks.

Kind regards
Mirish

On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello Everyone,
I tried your suggestions and it somehow helped me.
Now my doubt is " If I want to increase my number of iterations, what steps I 
have to do"?
Please help me out
Regards
Surbhi Aggarwal


On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
I also suspect that the network becomes disconnected by removing certain lines. 
You can check the connectivity using 
case_info()<https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or 
find_islands()<https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
 If there are islands, then each island needs to have its own reference bus, 
and the local generation needs to be able to meet the local load in each island.

Ray


On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

Could you please check the continuity of the system before running opf? I mean 
to say if you run opf for (n-1) criteria the system should be still well 
connected. There shouldn't be any island within the system itself. Perhaps you 
can test your model by removing any one parallel line (which you can observe 
later for analysis) and run the model under (n-1) criteria. This could be the 
easiest way to test the model. Thank you.

Kind regards
Mirish


On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Dear All,
I am working on optimal power flow to find the contingency (N-1) situation of 
the system. For some of the line outage, certain output pops out

MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)

Newton's method power flow (power balance, polar) did not converge in 10 
iterations.

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

What to do to correct this error. It would be of great help.
Regards
Surbhi Aggarwal

Re: Optimal power flow with DG connected

[Surbhi Aggarwal]

Hello
If the system does not converge within 10 iterations, can we say that it is
one of the most severely affected lines in contingency studies?
Or any other explanation for this non-convergence?
Regards
Surbhi Aggarwal


On Sat, Sep 12, 2020 at 10:40 AM Surbhi Aggarwal 
wrote:

> Hello
> Thank you all for your help and I'll definitely look out for the solutions.
> Thank you so much
> Regards
> Surbhi Aggarwal
>
>
> On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
> wrote:
>
>> Hi Surbhi,
>>
>> It looks like you were using the default Newton power flow. To increase
>> the number of iterations, you can increase the pf.nr.max_it option.
>> However, this is rarely necessary. If the Newton method is going to
>> converge, it usually does so in less than the default 10 iterations. If it
>> is not converging within 10 iterations, it is likely that the problem has
>> no solution or that you need a better starting point.
>>
>>Ray
>>
>>
>> On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
>> wrote:
>>
>> Hi Surbhi,
>>
>> First of all why do you want to increase the number of steps/ iterations
>> in the calculation? Is there any specific need? Actually the number of
>> iterations depends on the power flow optimization tolerance. Maybe you can
>> focus on the mpoption function and read it carefully. You can update
>> something like here:
>> mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
>> I'm not 100 % sure about it but it may help you. Thanks.
>>
>> Kind regards
>> Mirish
>>
>> On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal <
>> surbhiaggarwa...@gmail.com> wrote:
>>
>>> Hello Everyone,
>>> I tried your suggestions and it somehow helped me.
>>> Now my doubt is " If I want to increase my number of iterations, what
>>> steps I have to do"?
>>> Please help me out
>>> Regards
>>> Surbhi Aggarwal
>>>
>>>
>>> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
>>> wrote:
>>>
>>>> I also suspect that the network becomes disconnected by removing
>>>> certain lines. You can check the connectivity using case_info()
>>>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>>>> find_islands()
>>>> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>. If
>>>> there are islands, then each island needs to have its own reference bus,
>>>> and the local generation needs to be able to meet the local load in each
>>>> island.
>>>>
>>>> Ray
>>>>
>>>>
>>>> On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
>>>> wrote:
>>>>
>>>> Hi Surbhi,
>>>>
>>>> Could you please check the continuity of the system before running opf?
>>>> I mean to say if you run opf for (n-1) criteria the system should be still
>>>> well connected. There shouldn't be any island within the system itself.
>>>> Perhaps you can test your model by removing any one parallel line (which
>>>> you can observe later for analysis) and run the model under (n-1) criteria.
>>>> This could be the easiest way to test the model. Thank you.
>>>>
>>>> Kind regards
>>>> Mirish
>>>>
>>>>
>>>> On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal <
>>>> surbhiaggarwa...@gmail.com> wrote:
>>>>
>>>>> Dear All,
>>>>> I am working on optimal power flow to find the contingency (N-1)
>>>>> situation of the system. For some of the line outage, certain output pops
>>>>> out
>>>>>
>>>>> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
>>>>> Warning: Matrix is singular to working precision.
>>>>> > In mplinsolve (line 75)
>>>>>   In newtonpf (line 110)
>>>>>   In runpf (line 260)
>>>>> Warning: Matrix is singular to working precision.
>>>>> > In mplinsolve (line 75)
>>>>>   In newtonpf (line 110)
>>>>>   In runpf (line 260)
>>>>> Warning: Matrix is singular to working precision.
>>>>> > In mplinsolve (line 75)
>>>>>   In newtonpf (line 110)
>>>>>   In runpf (line 260)
>>>>> Warning: Matrix is singular to working precision.
>>>>> > In mplinsolve (line 75)
>>>>>   In newtonpf (line

Re: Optimal power flow with DG connected

[Surbhi Aggarwal]

Hello
Thank you all for your help and I'll definitely look out for the solutions.
Thank you so much
Regards
Surbhi Aggarwal


On Fri, Sep 11, 2020 at 7:16 PM Ray Daniel Zimmerman 
wrote:

> Hi Surbhi,
>
> It looks like you were using the default Newton power flow. To increase
> the number of iterations, you can increase the pf.nr.max_it option.
> However, this is rarely necessary. If the Newton method is going to
> converge, it usually does so in less than the default 10 iterations. If it
> is not converging within 10 iterations, it is likely that the problem has
> no solution or that you need a better starting point.
>
>Ray
>
>
> On Sep 11, 2020, at 5:48 AM, Mirish Thakur  wrote:
>
> Hi Surbhi,
>
> First of all why do you want to increase the number of steps/ iterations
> in the calculation? Is there any specific need? Actually the number of
> iterations depends on the power flow optimization tolerance. Maybe you can
> focus on the mpoption function and read it carefully. You can update
> something like here:
> mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
> I'm not 100 % sure about it but it may help you. Thanks.
>
> Kind regards
> Mirish
>
> On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal <
> surbhiaggarwa...@gmail.com> wrote:
>
>> Hello Everyone,
>> I tried your suggestions and it somehow helped me.
>> Now my doubt is " If I want to increase my number of iterations, what
>> steps I have to do"?
>> Please help me out
>> Regards
>> Surbhi Aggarwal
>>
>>
>> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
>> wrote:
>>
>>> I also suspect that the network becomes disconnected by removing certain
>>> lines. You can check the connectivity using case_info()
>>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>>> find_islands()
>>> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>. If
>>> there are islands, then each island needs to have its own reference bus,
>>> and the local generation needs to be able to meet the local load in each
>>> island.
>>>
>>> Ray
>>>
>>>
>>> On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
>>> wrote:
>>>
>>> Hi Surbhi,
>>>
>>> Could you please check the continuity of the system before running opf?
>>> I mean to say if you run opf for (n-1) criteria the system should be still
>>> well connected. There shouldn't be any island within the system itself.
>>> Perhaps you can test your model by removing any one parallel line (which
>>> you can observe later for analysis) and run the model under (n-1) criteria.
>>> This could be the easiest way to test the model. Thank you.
>>>
>>> Kind regards
>>> Mirish
>>>
>>>
>>> On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal <
>>> surbhiaggarwa...@gmail.com> wrote:
>>>
>>>> Dear All,
>>>> I am working on optimal power flow to find the contingency (N-1)
>>>> situation of the system. For some of the line outage, certain output pops
>>>> out
>>>>
>>>> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>> Warning: Matrix is singular to working precision.
>>>> > In mplinsolve (line 75)
>>>>   In newtonpf (line 110)
>>>>   In runpf (line 260)
>>>>
>>>> Newton's method power flow (power balance, polar) did not converge in
>>>> 10 iterations.
>>>>
>>>> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>>>>
>>>> What to do to correct this error. It would be of great help.
>>>> Regards
>>>> Surbhi Aggarwal
>>>>
>>>
>>>
>

Re: Optimal power flow with DG connected

[Ray Daniel Zimmerman]

Hi Surbhi,

It looks like you were using the default Newton power flow. To increase the 
number of iterations, you can increase the pf.nr.max_it option. However, this 
is rarely necessary. If the Newton method is going to converge, it usually does 
so in less than the default 10 iterations. If it is not converging within 10 
iterations, it is likely that the problem has no solution or that you need a 
better starting point.

   Ray


On Sep 11, 2020, at 5:48 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

First of all why do you want to increase the number of steps/ iterations in the 
calculation? Is there any specific need? Actually the number of iterations 
depends on the power flow optimization tolerance. Maybe you can focus on the 
mpoption function and read it carefully. You can update something like here:
mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
I'm not 100 % sure about it but it may help you. Thanks.

Kind regards
Mirish

On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Hello Everyone,
I tried your suggestions and it somehow helped me.
Now my doubt is " If I want to increase my number of iterations, what steps I 
have to do"?
Please help me out
Regards
Surbhi Aggarwal


On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
mailto:r...@cornell.edu>> wrote:
I also suspect that the network becomes disconnected by removing certain lines. 
You can check the connectivity using 
case_info()<https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or 
find_islands()<https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
 If there are islands, then each island needs to have its own reference bus, 
and the local generation needs to be able to meet the local load in each island.

Ray


On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

Could you please check the continuity of the system before running opf? I mean 
to say if you run opf for (n-1) criteria the system should be still well 
connected. There shouldn't be any island within the system itself. Perhaps you 
can test your model by removing any one parallel line (which you can observe 
later for analysis) and run the model under (n-1) criteria. This could be the 
easiest way to test the model. Thank you.

Kind regards
Mirish


On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Dear All,
I am working on optimal power flow to find the contingency (N-1) situation of 
the system. For some of the line outage, certain output pops out

MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)

Newton's method power flow (power balance, polar) did not converge in 10 
iterations.

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

What to do to correct this error. It would be of great help.
Regards
Surbhi Aggarwal

Re: Optimal power flow with DG connected

[Mirish Thakur]

Hi Surbhi,

First of all why do you want to increase the number of steps/ iterations in
the calculation? Is there any specific need? Actually the number of
iterations depends on the power flow optimization tolerance. Maybe you can
focus on the mpoption function and read it carefully. You can update
something like here:
mpopt = mpoption('pf.alg', 'FDXB', 'pf.tol', 1e-4)
I'm not 100 % sure about it but it may help you. Thanks.

Kind regards
Mirish

On Fri, Sep 11, 2020 at 8:41 AM Surbhi Aggarwal 
wrote:

> Hello Everyone,
> I tried your suggestions and it somehow helped me.
> Now my doubt is " If I want to increase my number of iterations, what
> steps I have to do"?
> Please help me out
> Regards
> Surbhi Aggarwal
>
>
> On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
> wrote:
>
>> I also suspect that the network becomes disconnected by removing certain
>> lines. You can check the connectivity using case_info()
>> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
>> find_islands()
>> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>. If
>> there are islands, then each island needs to have its own reference bus,
>> and the local generation needs to be able to meet the local load in each
>> island.
>>
>> Ray
>>
>>
>> On Sep 9, 2020, at 4:57 AM, Mirish Thakur  wrote:
>>
>> Hi Surbhi,
>>
>> Could you please check the continuity of the system before running opf? I
>> mean to say if you run opf for (n-1) criteria the system should be still
>> well connected. There shouldn't be any island within the system itself.
>> Perhaps you can test your model by removing any one parallel line (which
>> you can observe later for analysis) and run the model under (n-1) criteria.
>> This could be the easiest way to test the model. Thank you.
>>
>> Kind regards
>> Mirish
>>
>>
>> On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal <
>> surbhiaggarwa...@gmail.com> wrote:
>>
>>> Dear All,
>>> I am working on optimal power flow to find the contingency (N-1)
>>> situation of the system. For some of the line outage, certain output pops
>>> out
>>>
>>> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>> Warning: Matrix is singular to working precision.
>>> > In mplinsolve (line 75)
>>>   In newtonpf (line 110)
>>>   In runpf (line 260)
>>>
>>> Newton's method power flow (power balance, polar) did not converge in 10
>>> iterations.
>>>
>>> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>>>
>>> What to do to correct this error. It would be of great help.
>>> Regards
>>> Surbhi Aggarwal
>>>
>>
>>

Re: Optimal power flow with DG connected

[Surbhi Aggarwal]

Hello Everyone,
I tried your suggestions and it somehow helped me.
Now my doubt is " If I want to increase my number of iterations, what steps
I have to do"?
Please help me out
Regards
Surbhi Aggarwal


On Wed, Sep 9, 2020 at 7:50 PM Ray Daniel Zimmerman 
wrote:

> I also suspect that the network becomes disconnected by removing certain
> lines. You can check the connectivity using case_info()
> <https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or
> find_islands()
> <https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>. If
> there are islands, then each island needs to have its own reference bus,
> and the local generation needs to be able to meet the local load in each
> island.
>
> Ray
>
>
> On Sep 9, 2020, at 4:57 AM, Mirish Thakur  wrote:
>
> Hi Surbhi,
>
> Could you please check the continuity of the system before running opf? I
> mean to say if you run opf for (n-1) criteria the system should be still
> well connected. There shouldn't be any island within the system itself.
> Perhaps you can test your model by removing any one parallel line (which
> you can observe later for analysis) and run the model under (n-1) criteria.
> This could be the easiest way to test the model. Thank you.
>
> Kind regards
> Mirish
>
>
> On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
> wrote:
>
>> Dear All,
>> I am working on optimal power flow to find the contingency (N-1)
>> situation of the system. For some of the line outage, certain output pops
>> out
>>
>> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>> Warning: Matrix is singular to working precision.
>> > In mplinsolve (line 75)
>>   In newtonpf (line 110)
>>   In runpf (line 260)
>>
>> Newton's method power flow (power balance, polar) did not converge in 10
>> iterations.
>>
>> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>>
>> What to do to correct this error. It would be of great help.
>> Regards
>> Surbhi Aggarwal
>>
>
>

Re: optimal power flow with unit commitment using mixed integer programming

[yangyang]

Thank you for you interpretation Prof Ray. Actually I have found  a 
function called sgvm_add_shunts() in matpower -> extras ->syngrid, 
which looks like  it may do what I want, but I am not sure because there 
is not too much annotation in its source code and user's manual.





- 
"MATPOWER discussion forum" 
   

Re: optimal power flow with unit commitment using mixed integer programming

[Ray Daniel Zimmerman]

So runuopf() begins by running an OPF with all generators turned on, with 
active power dispatches limited by PMIN and PMAX. Any unit that is dispatched 
at PMIN (and would be dispatched lower if the limit were relaxed) is said to 
have a binding PMIN limit and is therefore considered as a candidate for 
shutdown. It re-runs the OPF with each of these candidates shut down (one at a 
time) and continues the process with the one that produced the greatest 
decrease in objective function … terminating when the objective is not 
decreased by shutting down any of the units dispatched at PMIN.

So on second thought, since your "shunt generators” are always dispatched at 
PMIN (since PMIN = PMAX), they are always candidates for shutdown, so long as 
the nodal price of active power is positive. This means that runuopf() may 
actually give you a decent approximation to the solution of the problem after 
all. The last condition (positive nodal price) is necessary to ensure that it 
is the PMIN limit that is binding, not the PMAX limit. The binding limit is the 
one that would alter the solution if it were relaxed.

However, runuopf() still requires that the problem be feasible with all 
generators turned on. It will not be able to shut down units to turn an 
infeasible problem into a feasible one … only to decrease the cost of a 
feasible problem.

  Ray



On Sep 9, 2020, at 9:33 PM, yangyang 
<980182...@qq.com<mailto:980182...@qq.com>> wrote:

Thank you for your suggestion Prof Ray. Actually I am still learning about the 
mechanism of uopf() and I dont really understand what binding Pmin limits 
means. In the attached files, if the cases with and without shunt generators 
have the same limits of voltage magnitude, the case with shunt generators will 
have less cost using runuopf() and it seems that the shunt with -8Mvar Qg will 
be shut down to avoid voltage magnitude violation. I dont know if this is the 
correct result. And thank you for your invitation, but I am a newbie at 
optimization. I really doubt if I could help in creating a convenient and 
integrated interface like runpf() and runopf() to implement mixed integer 
programming using other solvers. There is still quite a lot for me to learn.



"MATPOWER discussion forum" mailto:r...@cornell.edu>>;
2020年9月9日(星期三) 晚上9:57
"MATPOWER-L"mailto:matpowe...@list.cornell.edu>>;
Re: optimal power flow with unit commitment using mixed integer programming

Unfortunately, I do not believe runuopf() will work for this problem, since it 
uses heuristics to de-commit units one at a time based only on binding Pmin 
limits, not on binding reactive power limits, which is what you would need. I 
suppose you could modify uopf() to look at both, but in the end you still have 
a very crude and inefficient heuristic for dealing with the binary decisions, 
with no guarantees on the final optimality gap.

The proper way to solve this problem would be to create an interface in 
MP-Opt-Model for a mixed-integer nonlinear programming solver. Knitro has these 
capabilities, but they have not (yet) been implemented in MP-Opt-Model’s Knitro 
interface. We have nlps_knitro(), but we need a minlps_knitro(). There is also 
a suggestion in the issue tracker to include an interface for 
Bonmin<https://github.com/MATPOWER/mp-opt-model/issues/1>  which also handles 
MINLP problems. Both would be very welcome and useful additions.

Any chance you have time to work on this? I’d be happy to lend my support.

   Ray

?????? optimal power flow with unit commitment using mixed integer programming

[yangyang]

Thank you for your suggestion Prof Ray. Actually I am still learning about the 
mechanism of uopf() and I dont really understand what binding Pmin limits 
means. In the attached files, if the cases with and without shunt generators 
have the same limits of voltage magnitude, the case with shunt generators will 
have less cost using runuopf() and it seems that the shunt with -8Mvar Qg will 
be shut down to avoid voltage magnitude violation. I dont know if this is the 
correct result. And thank you for your invitation, but I am a newbie at 
optimization. I really doubt if I could help in creating a convenient and 
integrated interface like runpf() and runopf() to implement mixed integer 
programming using other solvers. There is still quite a lot for me to learn.






"MATPOWER discussion forum" 
   

?????? optimal power flow with unit commitment using mixed integer programming

[yangyang]

Thank you amini, but I dont really learn much about PSO. Do you mean partical 
swarm optimization? I think I need more time to learn about it.




--  --
??: 
   "MATPOWER discussion forum"  
  

Re: Optimal power flow with DG connected

[Ray Daniel Zimmerman]

I also suspect that the network becomes disconnected by removing certain lines. 
You can check the connectivity using 
case_info()<https://matpower.org/docs/ref/matpower7.0/lib/case_info.html> or 
find_islands()<https://matpower.org/docs/ref/matpower7.0/lib/find_islands.html>.
 If there are islands, then each island needs to have its own reference bus, 
and the local generation needs to be able to meet the local load in each island.

Ray


On Sep 9, 2020, at 4:57 AM, Mirish Thakur 
mailto:mirishtha...@gmail.com>> wrote:

Hi Surbhi,

Could you please check the continuity of the system before running opf? I mean 
to say if you run opf for (n-1) criteria the system should be still well 
connected. There shouldn't be any island within the system itself. Perhaps you 
can test your model by removing any one parallel line (which you can observe 
later for analysis) and run the model under (n-1) criteria. This could be the 
easiest way to test the model. Thank you.

Kind regards
Mirish


On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
mailto:surbhiaggarwa...@gmail.com>> wrote:
Dear All,
I am working on optimal power flow to find the contingency (N-1) situation of 
the system. For some of the line outage, certain output pops out

MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)

Newton's method power flow (power balance, polar) did not converge in 10 
iterations.

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

What to do to correct this error. It would be of great help.
Regards
Surbhi Aggarwal

Re: optimal power flow with unit commitment using mixed integer programming

[Ray Daniel Zimmerman]

Unfortunately, I do not believe runuopf() will work for this problem, since it 
uses heuristics to de-commit units one at a time based only on binding Pmin 
limits, not on binding reactive power limits, which is what you would need. I 
suppose you could modify uopf() to look at both, but in the end you still have 
a very crude and inefficient heuristic for dealing with the binary decisions, 
with no guarantees on the final optimality gap.

The proper way to solve this problem would be to create an interface in 
MP-Opt-Model for a mixed-integer nonlinear programming solver. Knitro has these 
capabilities, but they have not (yet) been implemented in MP-Opt-Model’s Knitro 
interface. We have nlps_knitro(), but we need a minlps_knitro(). There is also 
a suggestion in the issue tracker to include an interface for 
Bonmin<https://github.com/MATPOWER/mp-opt-model/issues/1>  which also handles 
MINLP problems. Both would be very welcome and useful additions.

Any chance you have time to work on this? I’d be happy to lend my support.

   Ray


On Sep 9, 2020, at 7:47 AM, yangyang 
<980182...@qq.com<mailto:980182...@qq.com>> wrote:

Dear Alireza SalimAmini

Thank you for your care and blessing. I think I have implemented this using 
runuopf(), a built-in function of matpower to do mixed unit commitment and OPF. 
In such cases where geneators are used to model shunt capacitors and reactors, 
just add a few generators whose real power generation Pg is zero and reactive 
power generation Qg set at a constant value. The Qmax and Qmin in generator 
data has to be identical with the set Qg. Notably, the Pmax and Pmin cannot be 
set to zero because runuopf() will merely deal with generators whose Pmin is 
greater than zero (see source codes of uopf() ). To get "shunt" generators 
involved as candidates of unit commitment programming only calls for Pmin and 
Pmax set at a very small number numerically, say, 1e-6 and 1e-5. This minor 
active power injection will hardly affect the power flow but can get "shunt" 
generators involved.


-- 原始邮件 --
发件人: "MATPOWER discussion forum" 
mailto:a.salimam...@gmail.com>>;
发送时间: 2020年9月9日(星期三) 下午2:22
收件人: "MATPOWER discussion 
forum"mailto:matpowe...@list.cornell.edu>>;
主题: Re: optimal power flow with unit commitment using mixed integer programming

hi
i wish u are healthy at this conditions( Covid19)
i think if you adjust Qmin and Qmax of capacitors at 'gen' matrix equal to 
6Mvar, it will help , and you can use status ( it is a column in gen matrix as 
came below)   of that capacitor a variable for reactive power balance.

'8  GEN_STATUS  status, > 0 - in service, <= 0 - out of service'

On Wed, Sep 9, 2020 at 6:34 AM yangyang 
<980182...@qq.com<mailto:980182...@qq.com>> wrote:
Dear all,
I am working on optimal power flow whose objective is the cost of generation 
plus the quadratic deviation of voltage magnitudes to 1.0.  The special part of 
the optimization lies in it that it has to include shunt capacitors and 
reactors in this network apart from conventional generators, which can control 
reactive power and voltages. In this network, the capacitors and reactors are 
modelled as discrete constant reactive power loads, whose values are like 0, 
-6MVar, -12MVar, -18MVar, etc.  I think a practical implementation is to take 
these shunt capacitors as a bunch of generators whose active power generation 
is set to 0 and reactive power generation set to constant values. Say, a chain 
of 6*6MVar shunt capacitors at one bus can be viewed as 6 generators at this 
bus whose active gen is 0 and reactive gen is 6MVar. On my opinion, these shunt 
capacitor or reactor generators should not change their active and reactive 
generation in OPF but only decide which generators should be on, just like unit 
commitment, while other conventional generators will change their active and 
reactive generation continously as conventional OPF. I dont know if it is 
practical using matpower. Despite the miqps_matpower function and the 
new-released mp-opt-model, it seems that no one has done so ever. Would you 
please help me with it? Thank you for you kind patience and consideration.

Re: optimal power flow with unit commitment using mixed integer programming

[Alireza SalimAmini]

if you use an optimization algorithm like pso or ...
define a variable for location and another variable for size of capacitor
this way is seeing that as generator

X is particles sets

this is one part of the code i copied because there are many mfiles
capacitor%
% x is variable (location and size of Capacitor)
% x(1) is siting
% x(2) is size
% f objective function
%--- place capacitor
MVAR_max=1;
Site_Cap=round(2 + 31*x(1)); % location of capacitor (bus 2 to bus 33)
Size_Cap=MVAR_max*x(2); % size of capacitor
data=case33bw; % call load flow input data (case 33_bus)
data.gen(2,8)=1; % turn on capacitor at bus

data.gen(2,3)=Size_Cap; % place capacitor
data.gen(2,1)=Site_Cap;
data.gencost(2,:)=[ 2 0 0 0 0 0 0   ];
***

but if you want to see it as reactive power at buses
  use something like this for  capacitor steps

Q=6*(round( 6*rand))
mpc.bus(k,6) = Q
k is number of bus


On Wed, Sep 9, 2020 at 5:48 PM yangyang <980182...@qq.com> wrote:

> That is also a good idea and closer to reality because shunt capacitors
> and reactors will actually change the Ybus instead of performing as
> constant reactive power. But I dont know how to include the 6th column of
> bus as a variable and modify the objective function. Would you please share
> your code with me? Thank you for your kind consideration. Here is my code.
>
>
> -- Original Mail --
> *发件人:* "MATPOWER discussion forum" ;
> *发送时间:* 2020年9月9日(星期三) 晚上9:31
> *收件人:* "MATPOWER discussion forum";
> *主题:* Re: optimal power flow with unit commitment using mixed integer
> programming
>
> and how about bus matrix column  6 ?
> " 6  BS  Bs, shunt susceptance (MVAr injected at V = 1.0 p.u.)"
> but in this case you have to define an objective function and solve an
> optimization problem.
> i used that for ieee 33 bus and the result was good.
>
>
> On Wed, Sep 9, 2020 at 5:20 PM yangyang <980182...@qq.com> wrote:
>
>> Dear Alireza SalimAmini
>>
>> Thank you for your care and blessing. I think I have implemented this
>> using runuopf(), a built-in function of matpower to do mixed unit
>> commitment and OPF. In such cases where geneators are used to model shunt
>> capacitors and reactors, just add a few generators whose real power
>> generation Pg is zero and reactive power generation Qg set at a constant
>> value. The Qmax and Qmin in generator data has to be identical with the set
>> Qg. Notably, the Pmax and Pmin cannot be set to zero because runuopf() will
>> merely deal with generators whose Pmin is greater than zero (see source
>> codes of uopf() ). To get "shunt" generators involved as candidates of unit
>> commitment programming only calls for Pmin and Pmax set at a very small
>> number numerically, say, 1e-6 and 1e-5. This minor active power injection
>> will hardly affect the power flow but can get "shunt" generators involved.
>>
>>
>>

?????? optimal power flow with unit commitment using mixed integer programming

[yangyang]

That is also a good idea and closer to reality because shunt capacitors and 
reactors will actually change the Ybus instead of performing as constant 
reactive power. But I dont know how to include the 6th column of bus as a 
variable and modify the objective function. Would you please share your code 
with me? Thank you for your kind consideration. Here is my code.




-- Original Mail --
??: 
   "MATPOWER discussion forum"  
  


case30wind.m
Description: Binary data


shunt_OPF.m
Description: Binary data

Re: optimal power flow with unit commitment using mixed integer programming

[Alireza SalimAmini]

and how about bus matrix column  6 ?
" 6  BS  Bs, shunt susceptance (MVAr injected at V = 1.0 p.u.)"
but in this case you have to define an objective function and solve an
optimization problem.
i used that for ieee 33 bus and the result was good.


On Wed, Sep 9, 2020 at 5:20 PM yangyang <980182...@qq.com> wrote:

> Dear Alireza SalimAmini
>
> Thank you for your care and blessing. I think I have implemented this
> using runuopf(), a built-in function of matpower to do mixed unit
> commitment and OPF. In such cases where geneators are used to model shunt
> capacitors and reactors, just add a few generators whose real power
> generation Pg is zero and reactive power generation Qg set at a constant
> value. The Qmax and Qmin in generator data has to be identical with the set
> Qg. Notably, the Pmax and Pmin cannot be set to zero because runuopf() will
> merely deal with generators whose Pmin is greater than zero (see source
> codes of uopf() ). To get "shunt" generators involved as candidates of unit
> commitment programming only calls for Pmin and Pmax set at a very small
> number numerically, say, 1e-6 and 1e-5. This minor active power injection
> will hardly affect the power flow but can get "shunt" generators involved.
>
>
> -- 原始邮件 --
> *发件人:* "MATPOWER discussion forum" ;
> *发送时间:* 2020年9月9日(星期三) 下午2:22
> *收件人:* "MATPOWER discussion forum";
> *主题:* Re: optimal power flow with unit commitment using mixed integer
> programming
>
> hi
> i wish u are healthy at this conditions( Covid19)
> i think if you adjust Qmin and Qmax of capacitors at 'gen' matrix equal to
> 6Mvar, it will help , and you can use status ( it is a column in gen matrix
> as came below)   of that capacitor a variable for reactive power balance.
>
> '8  GEN_STATUS  status, > 0 - in service, <= 0 - out of service'
>
> On Wed, Sep 9, 2020 at 6:34 AM yangyang <980182...@qq.com> wrote:
>
>> Dear all,
>> I am working on optimal power flow whose objective is the cost of
>> generation plus the quadratic deviation of voltage magnitudes to 1.0.  The
>> special part of the optimization lies in it that it has to include shunt
>> capacitors and reactors in this network apart from conventional generators,
>> which can control reactive power and voltages. In this network, the
>> capacitors and reactors are modelled as discrete constant reactive power
>> loads, whose values are like 0, -6MVar, -12MVar, -18MVar, etc.  I think a
>> practical implementation is to take these shunt capacitors as a bunch of
>> generators whose active power generation is set to 0 and reactive power
>> generation set to constant values. Say, a chain of 6*6MVar shunt capacitors
>> at one bus can be viewed as 6 generators at this bus whose active gen is 0
>> and reactive gen is 6MVar. On my opinion, these shunt capacitor or reactor
>> generators should not change their active and reactive generation in OPF
>> but only decide which generators should be on, just like unit commitment,
>> while other conventional generators will change their active and reactive
>> generation continously as conventional OPF. I dont know if it is practical
>> using matpower. Despite the miqps_matpower function and the new-released
>> mp-opt-model, it seems that no one has done so ever. Would you please help
>> me with it? Thank you for you kind patience and consideration.
>>
>

?????? optimal power flow with unit commitment using mixed integer programming

[yangyang]

Dear Alireza SalimAmini


Thank you for your care and blessing. I think I have implemented this using 
runuopf(), a built-in function of matpower to do mixed unit commitment and OPF. 
In such cases where geneators are used to model shunt capacitors and reactors, 
just add a few generators whose real power generation Pg is zero and reactive 
power generation Qg set at a constant value. The Qmax and Qmin in generator 
data has to be identical with the set Qg. Notably, the Pmax and Pmin cannot be 
set to zero because runuopf() will merely deal with generators whose Pmin is 
greater than zero (see source codes of uopf() ). To get "shunt" generators 
involved as candidates of unit commitment programming only calls for Pmin and 
Pmax set at a very small number numerically, say, 1e-6 and 1e-5. This minor 
active power injection will hardly affect the power flow but can get "shunt" 
generators involved.




--  --
??: 
   "MATPOWER discussion forum"  
  

Re: Optimal power flow with DG connected

[Mirish Thakur]

Hi Surbhi,

Could you please check the continuity of the system before running opf? I
mean to say if you run opf for (n-1) criteria the system should be still
well connected. There shouldn't be any island within the system itself.
Perhaps you can test your model by removing any one parallel line (which
you can observe later for analysis) and run the model under (n-1) criteria.
This could be the easiest way to test the model. Thank you.

Kind regards
Mirish


On Wed, Sep 9, 2020 at 9:11 AM Surbhi Aggarwal 
wrote:

> Dear All,
> I am working on optimal power flow to find the contingency (N-1) situation
> of the system. For some of the line outage, certain output pops out
>
> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
>
> Newton's method power flow (power balance, polar) did not converge in 10
> iterations.
>
> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>
> What to do to correct this error. It would be of great help.
> Regards
> Surbhi Aggarwal
>

Re: Optimal power flow with DG connected

[Md Ashfaqur Rahman]

Hi Surbhi,

The system is becoming unobservable, I guess.

Regards,
Md


On Wed, Sep 9, 2020, 2:12 AM Surbhi Aggarwal 
wrote:

> Dear All,
> I am working on optimal power flow to find the contingency (N-1) situation
> of the system. For some of the line outage, certain output pops out
>
> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
>
> Newton's method power flow (power balance, polar) did not converge in 10
> iterations.
>
> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>
> What to do to correct this error. It would be of great help.
> Regards
> Surbhi Aggarwal
>

Re: Optimal power flow with DG connected

[Jagadeesh Gunda]

Hi Surabhi,

It seems the problem is with your network, not with the power flow
algorithm.
*Technical interpretation:* For the generation and demand you are
targeting; your network is N-1 contingency incompliant.
*Mathematical interpretation:* Because of the above problem, power flow
Jacobian is becoming singular. As we know, Jacobian needs to be inverted in
every iteration. But inversion is failing because the matrix is singular.

You may correct the issue as below.

Solution-1: Increase the number of Newton Iterations and try again. But I
don’t think it will work.
Solution-2: Rather than disconnecting the line, change its impedance to
very large value. This should work, and it represents your outage
condition. You will see almost no flow on the line after power flow
converged.
Solution-3: Take a different network.
Solution-4: Fix your network first, and then analyze your scenario again.

Best Regards,
Dr  JGunda
Optimization Engineer
Power Systems & Electricity Markets
*GE Grid Solutions Denmark*
LinkedIn: https://www.linkedin.com/in/jgunda/
Google Scholar:
https://scholar.google.co.uk/citations?user=Zy1m33QJ&hl=en
ResearchGate: https://www.researchgate.net/profile/Jagadeesh_Gunda


On Wed, 9 Sep 2020 at 09:12, Surbhi Aggarwal 
wrote:

> Dear All,
> I am working on optimal power flow to find the contingency (N-1) situation
> of the system. For some of the line outage, certain output pops out
>
> MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
> Warning: Matrix is singular to working precision.
> > In mplinsolve (line 75)
>   In newtonpf (line 110)
>   In runpf (line 260)
>
> Newton's method power flow (power balance, polar) did not converge in 10
> iterations.
>
> >>>>>  Did NOT converge (7.38 seconds)  <<<<<
>
> What to do to correct this error. It would be of great help.
> Regards
> Surbhi Aggarwal
>

Re: Optimal power flow with DG connected

[sebaa haddi]

 Try with DC power flow 

Le mercredi 9 septembre 2020 à 08:11:45 UTC+1, Surbhi Aggarwal 
 a écrit :  
 
 Dear All,I am working on optimal power flow to find the contingency (N-1) 
situation of the system. For some of the line outage, certain output pops out
MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 
Warning: Matrix is singular to working precision. 
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260) 

Newton's method power flow (power balance, polar) did not converge in 10 
iterations.

>>>>>  Did NOT converge (7.38 seconds)  <<<<<
What to do to correct this error. It would be of great help.
RegardsSurbhi Aggarwal  

Optimal power flow with DG connected

[Surbhi Aggarwal]

Dear All,
I am working on optimal power flow to find the contingency (N-1) situation
of the system. For some of the line outage, certain output pops out

MATPOWER Version 7.0, 20-Jun-2019 -- AC Power Flow (Newton)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)
Warning: Matrix is singular to working precision.
> In mplinsolve (line 75)
  In newtonpf (line 110)
  In runpf (line 260)

Newton's method power flow (power balance, polar) did not converge in 10
iterations.

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

What to do to correct this error. It would be of great help.
Regards
Surbhi Aggarwal

Re: optimal power flow with unit commitment using mixed integer programming

[Alireza SalimAmini]

hi
i wish u are healthy at this conditions( Covid19)
i think if you adjust Qmin and Qmax of capacitors at 'gen' matrix equal to
6Mvar, it will help , and you can use status ( it is a column in gen matrix
as came below)   of that capacitor a variable for reactive power balance.

'8  GEN_STATUS  status, > 0 - in service, <= 0 - out of service'

On Wed, Sep 9, 2020 at 6:34 AM yangyang <980182...@qq.com> wrote:

> Dear all,
> I am working on optimal power flow whose objective is the cost of
> generation plus the quadratic deviation of voltage magnitudes to 1.0.  The
> special part of the optimization lies in it that it has to include shunt
> capacitors and reactors in this network apart from conventional generators,
> which can control reactive power and voltages. In this network, the
> capacitors and reactors are modelled as discrete constant reactive power
> loads, whose values are like 0, -6MVar, -12MVar, -18MVar, etc.  I think a
> practical implementation is to take these shunt capacitors as a bunch of
> generators whose active power generation is set to 0 and reactive power
> generation set to constant values. Say, a chain of 6*6MVar shunt capacitors
> at one bus can be viewed as 6 generators at this bus whose active gen is 0
> and reactive gen is 6MVar. On my opinion, these shunt capacitor or reactor
> generators should not change their active and reactive generation in OPF
> but only decide which generators should be on, just like unit commitment,
> while other conventional generators will change their active and reactive
> generation continously as conventional OPF. I dont know if it is practical
> using matpower. Despite the miqps_matpower function and the new-released
> mp-opt-model, it seems that no one has done so ever. Would you please help
> me with it? Thank you for you kind patience and consideration.
>

optimal power flow with unit commitment using mixed integer programming

[yangyang]

Dear all,
I am working on optimal power flow whose objective is the cost of generation 
plus the quadratic deviation of voltage magnitudes to 1.0.  The special 
part of the optimization lies in it that it has to include shunt capacitors and 
reactors in this network apart from conventional generators, which can control 
reactive power and voltages. In this network, the capacitors and reactors are 
modelled as discrete constant reactive power loads, whose values are like 0, 
-6MVar, -12MVar, -18MVar, etc.  I think a practical implementation is to 
take these shunt capacitors as a bunch of generators whose active power 
generation is set to 0 and reactive power generation set to constant values. 
Say, a chain of 6*6MVar shunt capacitors at one bus can be viewed as 6 
generators at this bus whose active gen is 0 and reactive gen is 6MVar. On my 
opinion, these shunt capacitor or reactor generators should not change their 
active and reactive generation in OPF but only decide which generators should 
be on, just like unit commitment, while other conventional generators will 
change their active and reactive generation continously as conventional OPF. I 
dont know if it is practical using matpower. Despite the miqps_matpower 
function and the new-released mp-opt-model, it seems that no one has done so 
ever. Would you please help me with it? Thank you for you kind patience and 
consideration.

Re: Linear Approximations of Line Flow Constraints for AC Optimal Power Flow

[Ray Daniel Zimmerman]

MATPOWER does not implement such a thing, if that’s what you’re asking. I 
suppose you could use the derivatives of the flow constraints (or balance 
equations) in order to get a linear approximation at a given operating point.

   Ray


> On Feb 11, 2020, at 3:12 PM, hind lamini  wrote:
> 
> Hello everyone,
> 
> I’m trying to solve an AC OPF with  linear constraints on the line
> flows (power balance constraints). So ,can i have a Linear
> Approximations of Line Flow Constraints for AC Optimal Power Flow.
> 
> Best,
> 
> 

Linear Approximations of Line Flow Constraints for AC Optimal Power Flow

[hind lamini]

Hello everyone,

I’m trying to solve an AC OPF with  linear constraints on the line
flows (power balance constraints). So ,can i have a Linear
Approximations of Line Flow Constraints for AC Optimal Power Flow.

Best,

power flow voltage of bus 69 in 118 bus system

[naime ahmadi]

Hi
I have a question about state estimation in MATPOWER.
In 118 bus system the slack bus is 69. The voltage and angle on bus 69
should be 1 and 0.
But when I check Vlf (power flow voltage of bus 69) it is 0.9083 + 0.3784i.
So, when I check the error in function runse

plot(180/pi*(angle(Vlf)-angle(V)),'.')

It becomes big.

Is it correct to put voltage magnitude and angle of bus 69 in
the case 118 to one and zero?

Thanks,

Naime

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

Power flow while involving radial systems

[chixinx...@hotmail.com]

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
function mpc = case30
%CASE30Power flow data for 30 bus, 6 generator case.
%   Please see CASEFORMAT for details on the case file format.
%
%   Based on data from ...
% Alsac, O. & Stott, B., "Optimal Load Flow with Steady State Security",
% IEEE Transactions on Power Apparatus and Systems, Vol. PAS 93, No. 3,
% 1974, pp. 745-751.
%   ... with branch parameters rounded to nearest 0.01, shunt values divided
%   by 100 and shunt on bus 10 moved to bus 5, load at bus 5 zeroed out.
%   Generator locations, costs and limits and bus areas were taken from ...
% Ferrero, R.W., Shahidehpour, S.M., Ramesh, V.C., "Transaction analysis
% in deregulated power systems using game theory", IEEE Transactions on
% Power Systems, Vol. 12, No. 3, Aug 1997, pp. 1340-1347.
%   Generator Q limits were derived from Alsac & Stott, using their Pmax
%   capacities. V limits and line |S| limits taken from Alsac & Stott.

%   MATPOWER

%% MATPOWER Case Format : Version 2
mpc.version = '2';

%%-  Power Flow Data  -%%
%% system MVA base
mpc.baseMVA = 100;

%% bus data
%   bus_i   typePd  Qd  Gs  Bs  areaVm  Va  
baseKV  zoneVmaxVmin
mpc.bus = [
1   3   0   0   0   0   1   1   0   
135 1   1.050.95;
2   2   21.712.70   0   1   1   0   
135 1   1.1 0.95;
3   1   2.4 1.2 0   0   1   1   0   
135 1   1.050.95;
4   1   7.6 1.6 0   0   1   1   0   
135 1   1.050.95;
5   1   0   0   0   0.191   1   0   
135 1   1.050.95;
6   1   0   0   0   0   1   1   0   
135 1   1.050.95;
7   1   22.810.90   0   1   1   0   
135 1   1.050.95;
8   1   30  30  0   0   1   1   0   
135 1   1.050.95;
9   1   0   0   0   0   1   1   0   
135 1   1.050.95;
10  1   5.8 2   0   0   3   1   0   
135 1   1.050.95;
11  1   0   0   0   0   1   1   0   
135 1   1.050.95;
12  1   11.27.5 0   0   2   1   0   
135 1   1.050.95;
13  2   0   0   0   0   2   1   0   
135 1   1.1 0.95;
14  1   6.2 1.6 0   0   2   1   0   
135 1   1.050.95;
15  1   8.2 2.5 0   0   2   1   0   
135 1   1.050.95;
16  1   3.5 1.8 0   0   2   1   0   
135 1   1.050.95;
17  1   9   5.8 0   0   2   1   0   
135 1   1.050.95;
18  1   3.2 0.9 0   0   2   1   0   
135 1   1.050.95;
19  1   9.5 3.4 0   0   2   1   0   
135 1   1.050.95;
20  1   2.2 0.7 0   0   2   1   0   
135 1   1.050.95;
21  1   17.511.20   0   3   1   0   
135 1   1.050.95;
22  2   0   0   0   0   3   1   0   
135 1   1.1 0.95;
23  2   3.2 1.6 0   0   2   1   0   
135 1   1.1 0.95;
24  1   8.7 6.7 0   0.043   1   0   
135 1   1.050.95;
25  1   0   0   0   0   3   1   0   
135 1   1.050.95;
26  1   3.5 2.3 0   0   3   1   0   
135 1   1.050.95;
27  2   0   0   0   0   3   1   0   
135 1

Re: case13659pegase -> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE

[Aamir Nawaz]

Dear Dr. Maeght Jean,
You have given no information about simulation time required for solving
different cases in paper. Please can you share some file relating to
simulation time of solving these large-scale problems. Thanks.

Regards,
Aamir Nawaz

On Fri, Jul 19, 2019 at 12:24 AM MAEGHT Jean 
wrote:

> Hello,
>
> This test case was published in this paper, were indications on how to
> solve it with matpower are given. Looking into the zip file on arxiv web
> site, you will also find some matlab code to run opfs, using Knitro.
>
>
>
> https://arxiv.org/abs/1603.01533
>
> .tar.gz file : https://arxiv.org/e-print/1603.01533
> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and
> PEGASE
>
> Cédric Josz
> <https://arxiv.org/search/math?searchtype=author&query=Josz%2C+C>, Stéphane
> Fliscounakis
> <https://arxiv.org/search/math?searchtype=author&query=Fliscounakis%2C+S>,
> Jean Maeght
> <https://arxiv.org/search/math?searchtype=author&query=Maeght%2C+J>, Patrick
> Panciatici
> <https://arxiv.org/search/math?searchtype=author&query=Panciatici%2C+P>
>
> *(Submitted on 4 Mar 2016 (**v1 <https://arxiv.org/abs/1603.01533v1>**),
> last revised 30 Mar 2016 (this version, v3))*
>
> In this paper, we publish nine new test cases in MATPOWER format. Four
> test cases are French very high-voltage grid generated by the offline
> plateform of iTesla: part of the data was sampled. Four test cases are RTE
> snapshots of the full French very high-voltage and high-voltage grid that
> come from French SCADAs via the Convergence software. The ninth and largest
> test case is a pan-European ficticious data set that stems from the PEGASE
> project. It complements the four PEGASE test cases that we previously
> published in MATPOWER version 5.1 in March 2015. We also provide a MATLAB
> code to transform the data into standard mathematical optimization format.
> Computational results confirming the validity of the data are presented in
> this paper.
>
>
>
>
>
> Best regards,
>
> [image: logo]
>
> *Jean MAEGHT*
> RTE – R&D Division
>
> PES - Direction de la R&D
> T+33 658 248 320
>
> *jean.mae...@rte-france.com* 
>
>
>
>
>
>
>
>
>
> *De :* bounce-123756981-75398...@list.cornell.edu [mailto:
> bounce-123756981-75398...@list.cornell.edu] *De la part de* Aamir Nawaz
> *Envoyé :* jeudi 18 juillet 2019 17:59
> *À :* matpower-l@cornell.edu
> *Objet :* case13659pegase
>
>
>
> Dear Researchers,
>
>
>
> I have tried to execute the following and error comes. Can anyone explain
> why algorithm like PDIPM fails to solve this large system? However, i have
> solved it using evolutionary algorithm and it is converged. Is there any
> limit of number of dimensions for PDIPM or others? If no, then suggest me
> how i can solve it or suggest any other algorithm like SDPOPF etc. I
> waiting for your kind reply.
>
>
>
> runopf(case13659pegase)
>
> MATPOWER Version 6.0, 16-Dec-2016 -- AC Optimal Power Flow
> PDIPMOPF Version 4.1, Build 18, 11-Nov-2011
> Copyright (c) 2007-2011 by Power System Engineering Research Center (PSERC)
>
> >>>>>  Did NOT converge (4.42 seconds)  <<<<<
>
>
> --
>
>
>
> *Regards, Aamir Nawaz**.*
>
>
> "Ce message est destiné exclusivement aux personnes ou entités auxquelles
> il est adressé et peut contenir des informations privilégiées ou
> confidentielles. Si vous avez reçu ce document par erreur, merci de nous
> l'indiquer par retour, de ne pas le transmettre et de procéder à sa
> destruction.
>
> This message is solely intended for the use of the individual or entity to
> which it is addressed and may contain information that is privileged or
> confidential. If you have received this communication by error, please
> notify us immediately by electronic mail, do not disclose it and delete the
> original message."
>

RE: case13659pegase -> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE

[MAEGHT Jean]

Hello,
You have to rename the donwloaded file : add manually .tar.gz extension to the 
downloaded file.
There is no other link.
Best regards
Jean

De : bounce-123757332-75398...@list.cornell.edu 
[mailto:bounce-123757332-75398...@list.cornell.edu] De la part de Jubeyer Rahman
Envoyé : jeudi 18 juillet 2019 20:06
À : MATPOWER discussion forum 
Objet : Re: case13659pegase -> AC Power Flow Data in MATPOWER and QCQP Format: 
iTesla, RTE Snapshots, and PEGASE

Hi Jean,

I am having difficulty in downloading the zip file, can you provide another 
link if possible?

Regards,
Jubeyer


On Thu, Jul 18, 2019 at 11:24 AM MAEGHT Jean 
mailto:jean.mae...@rte-france.com>> wrote:
Hello,
This test case was published in this paper, were indications on how to solve it 
with matpower are given. Looking into the zip file on arxiv web site, you will 
also find some matlab code to run opfs, using Knitro.

https://arxiv.org/abs/1603.01533
.tar.gz file : https://arxiv.org/e-print/1603.01533
AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and 
PEGASE
Cédric Josz<https://arxiv.org/search/math?searchtype=author&query=Josz%2C+C>, 
Stéphane 
Fliscounakis<https://arxiv.org/search/math?searchtype=author&query=Fliscounakis%2C+S>,
 Jean 
Maeght<https://arxiv.org/search/math?searchtype=author&query=Maeght%2C+J>, 
Patrick 
Panciatici<https://arxiv.org/search/math?searchtype=author&query=Panciatici%2C+P>
(Submitted on 4 Mar 2016 (v1<https://arxiv.org/abs/1603.01533v1>), last revised 
30 Mar 2016 (this version, v3))
In this paper, we publish nine new test cases in MATPOWER format. Four test 
cases are French very high-voltage grid generated by the offline plateform of 
iTesla: part of the data was sampled. Four test cases are RTE snapshots of the 
full French very high-voltage and high-voltage grid that come from French 
SCADAs via the Convergence software. The ninth and largest test case is a 
pan-European ficticious data set that stems from the PEGASE project. It 
complements the four PEGASE test cases that we previously published in MATPOWER 
version 5.1 in March 2015. We also provide a MATLAB code to transform the data 
into standard mathematical optimization format. Computational results 
confirming the validity of the data are presented in this paper.


Best regards,
[logo]

Jean MAEGHT
RTE – R&D Division

PES - Direction de la R&D
T+33 658 248 320


jean.mae...@rte-france.com<mailto:jean.mae...@rte-france.com>





De : 
bounce-123756981-75398...@list.cornell.edu<mailto:bounce-123756981-75398...@list.cornell.edu>
 
[mailto:bounce-123756981-75398...@list.cornell.edu<mailto:bounce-123756981-75398...@list.cornell.edu>]
 De la part de Aamir Nawaz
Envoyé : jeudi 18 juillet 2019 17:59
À : matpower-l@cornell.edu<mailto:matpower-l@cornell.edu>
Objet : case13659pegase

Dear Researchers,

I have tried to execute the following and error comes. Can anyone explain why 
algorithm like PDIPM fails to solve this large system? However, i have solved 
it using evolutionary algorithm and it is converged. Is there any limit of 
number of dimensions for PDIPM or others? If no, then suggest me how i can 
solve it or suggest any other algorithm like SDPOPF etc. I waiting for your 
kind reply.

runopf(case13659pegase)
MATPOWER Version 6.0, 16-Dec-2016 -- AC Optimal Power Flow
PDIPMOPF Version 4.1, Build 18, 11-Nov-2011
Copyright (c) 2007-2011 by Power System Engineering Research Center (PSERC)

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

--

Regards,
Aamir Nawaz.


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il 
est adressé et peut contenir des informations privilégiées ou confidentielles. 
Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, 
de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to 
which it is addressed and may contain information that is privileged or 
confidential. If you have received this communication by error, please notify 
us immediately by electronic mail, do not disclose it and delete the original 
message."


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il 
est adressé et peut contenir des informations privilégiées ou confidentielles. 
Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, 
de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to 
which it is addressed and may contain information that is privileged or 
confidential. If you have received this communication by error, please notify 
us immediately by electronic mail, do not disclose it and delete the original 
message."

Re: case13659pegase -> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE

[Jubeyer Rahman]

Hi Jean,

I am having difficulty in downloading the zip file, can you provide another
link if possible?

Regards,
Jubeyer


On Thu, Jul 18, 2019 at 11:24 AM MAEGHT Jean 
wrote:

> Hello,
>
> This test case was published in this paper, were indications on how to
> solve it with matpower are given. Looking into the zip file on arxiv web
> site, you will also find some matlab code to run opfs, using Knitro.
>
>
>
> https://arxiv.org/abs/1603.01533
>
> .tar.gz file : https://arxiv.org/e-print/1603.01533
> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and
> PEGASE
>
> Cédric Josz
> <https://arxiv.org/search/math?searchtype=author&query=Josz%2C+C>, Stéphane
> Fliscounakis
> <https://arxiv.org/search/math?searchtype=author&query=Fliscounakis%2C+S>,
> Jean Maeght
> <https://arxiv.org/search/math?searchtype=author&query=Maeght%2C+J>, Patrick
> Panciatici
> <https://arxiv.org/search/math?searchtype=author&query=Panciatici%2C+P>
>
> *(Submitted on 4 Mar 2016 (**v1 <https://arxiv.org/abs/1603.01533v1>**),
> last revised 30 Mar 2016 (this version, v3))*
>
> In this paper, we publish nine new test cases in MATPOWER format. Four
> test cases are French very high-voltage grid generated by the offline
> plateform of iTesla: part of the data was sampled. Four test cases are RTE
> snapshots of the full French very high-voltage and high-voltage grid that
> come from French SCADAs via the Convergence software. The ninth and largest
> test case is a pan-European ficticious data set that stems from the PEGASE
> project. It complements the four PEGASE test cases that we previously
> published in MATPOWER version 5.1 in March 2015. We also provide a MATLAB
> code to transform the data into standard mathematical optimization format.
> Computational results confirming the validity of the data are presented in
> this paper.
>
>
>
>
>
> Best regards,
>
> [image: logo]
>
> *Jean MAEGHT*
> RTE – R&D Division
>
> PES - Direction de la R&D
> T+33 658 248 320
>
> *jean.mae...@rte-france.com* 
>
>
>
>
>
>
>
>
>
> *De :* bounce-123756981-75398...@list.cornell.edu [mailto:
> bounce-123756981-75398...@list.cornell.edu] *De la part de* Aamir Nawaz
> *Envoyé :* jeudi 18 juillet 2019 17:59
> *À :* matpower-l@cornell.edu
> *Objet :* case13659pegase
>
>
>
> Dear Researchers,
>
>
>
> I have tried to execute the following and error comes. Can anyone explain
> why algorithm like PDIPM fails to solve this large system? However, i have
> solved it using evolutionary algorithm and it is converged. Is there any
> limit of number of dimensions for PDIPM or others? If no, then suggest me
> how i can solve it or suggest any other algorithm like SDPOPF etc. I
> waiting for your kind reply.
>
>
>
> runopf(case13659pegase)
>
> MATPOWER Version 6.0, 16-Dec-2016 -- AC Optimal Power Flow
> PDIPMOPF Version 4.1, Build 18, 11-Nov-2011
> Copyright (c) 2007-2011 by Power System Engineering Research Center (PSERC)
>
> >>>>>  Did NOT converge (4.42 seconds)  <<<<<
>
>
> --
>
>
>
> *Regards, Aamir Nawaz**.*
>
>
> "Ce message est destiné exclusivement aux personnes ou entités auxquelles
> il est adressé et peut contenir des informations privilégiées ou
> confidentielles. Si vous avez reçu ce document par erreur, merci de nous
> l'indiquer par retour, de ne pas le transmettre et de procéder à sa
> destruction.
>
> This message is solely intended for the use of the individual or entity to
> which it is addressed and may contain information that is privileged or
> confidential. If you have received this communication by error, please
> notify us immediately by electronic mail, do not disclose it and delete the
> original message."
>

RE: case13659pegase -> AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE

[MAEGHT Jean]

Hello,
This test case was published in this paper, were indications on how to solve it 
with matpower are given. Looking into the zip file on arxiv web site, you will 
also find some matlab code to run opfs, using Knitro.

https://arxiv.org/abs/1603.01533
.tar.gz file : https://arxiv.org/e-print/1603.01533
AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and 
PEGASE
Cédric Josz<https://arxiv.org/search/math?searchtype=author&query=Josz%2C+C>, 
Stéphane 
Fliscounakis<https://arxiv.org/search/math?searchtype=author&query=Fliscounakis%2C+S>,
 Jean 
Maeght<https://arxiv.org/search/math?searchtype=author&query=Maeght%2C+J>, 
Patrick 
Panciatici<https://arxiv.org/search/math?searchtype=author&query=Panciatici%2C+P>
(Submitted on 4 Mar 2016 (v1<https://arxiv.org/abs/1603.01533v1>), last revised 
30 Mar 2016 (this version, v3))
In this paper, we publish nine new test cases in MATPOWER format. Four test 
cases are French very high-voltage grid generated by the offline plateform of 
iTesla: part of the data was sampled. Four test cases are RTE snapshots of the 
full French very high-voltage and high-voltage grid that come from French 
SCADAs via the Convergence software. The ninth and largest test case is a 
pan-European ficticious data set that stems from the PEGASE project. It 
complements the four PEGASE test cases that we previously published in MATPOWER 
version 5.1 in March 2015. We also provide a MATLAB code to transform the data 
into standard mathematical optimization format. Computational results 
confirming the validity of the data are presented in this paper.


Best regards,
[logo]

Jean MAEGHT
RTE – R&D Division

PES - Direction de la R&D
T+33 658 248 320


jean.mae...@rte-france.com<mailto:jean.mae...@rte-france.com>






De : bounce-123756981-75398...@list.cornell.edu 
[mailto:bounce-123756981-75398...@list.cornell.edu] De la part de Aamir Nawaz
Envoyé : jeudi 18 juillet 2019 17:59
À : matpower-l@cornell.edu
Objet : case13659pegase

Dear Researchers,

I have tried to execute the following and error comes. Can anyone explain why 
algorithm like PDIPM fails to solve this large system? However, i have solved 
it using evolutionary algorithm and it is converged. Is there any limit of 
number of dimensions for PDIPM or others? If no, then suggest me how i can 
solve it or suggest any other algorithm like SDPOPF etc. I waiting for your 
kind reply.

runopf(case13659pegase)
MATPOWER Version 6.0, 16-Dec-2016 -- AC Optimal Power Flow
PDIPMOPF Version 4.1, Build 18, 11-Nov-2011
Copyright (c) 2007-2011 by Power System Engineering Research Center (PSERC)

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

--

Regards,
Aamir Nawaz.


"Ce message est destiné exclusivement aux personnes ou entités auxquelles il 
est adressé et peut contenir des informations privilégiées ou confidentielles. 
Si vous avez reçu ce document par erreur, merci de nous l'indiquer par retour, 
de ne pas le transmettre et de procéder à sa destruction.

This message is solely intended for the use of the individual or entity to 
which it is addressed and may contain information that is privileged or 
confidential. If you have received this communication by error, please notify 
us immediately by electronic mail, do not disclose it and delete the original 
message."

Re: CPF power flow did not converge

[W Ruoyu]

Hi,

Thanks for the reply, I have decreased the load and now my cpf is converged.

Best regards,
Cynthia



在 2019年7月11日，19:30，Abhyankar, Shrirang G 
mailto:shrirang.abhyan...@pnnl.gov>> 写道：

Cynthia,
   Please see this MATPOWER  FAQ<https://matpower.org/doc/faq/#pfconvergence> 
on debugging power flow divergence. Also, you forgot to attach your case file.

Thanks,
Shri


From: 
mailto:bounce-123739424-83373...@list.cornell.edu>>
 on behalf of W Ruoyu 
mailto:cynthiaw1...@hotmail.com>>
Reply-To: MATPOWER discussion forum 
mailto:matpowe...@list.cornell.edu>>
Date: Thursday, July 11, 2019 at 10:54 AM
To: "MATPOWER-L@cornell.edu<mailto:MATPOWER-L@cornell.edu>" 
mailto:MATPOWER-L@cornell.edu>>
Subject: CPF power flow did not converge

Hi all,

I am trying to analyse the influence of topology changes (like disconnect 
branches) on system voltage stability using the following code:

define_constants;



mpc =loadcase('FourAreaNetwork');   "
OutmailID: 123739424, List: 'matpower-l', MemberID: 83373175
SCRIPT: "load basecase
mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1];"
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "invalid command name 
"0,0,1,0,1,1,1,1,1,1"change branch status

mpopt = mpoption('out.all',0,'verbose',2,'out.bus',1);
mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05);
mpct = mpc;  "
OutmailID: 123739424, List: 'matpower-l', MemberID: 83373175
SCRIPT: "set up target case with basecase
mpct.gen(:,[PG QG]) = mpc.gen(:,[PG QG])*2
mpct.bus(:,[PD QD]) = mpc.bus(:,[PD QD])*2
results = runcpf(mpc, mpct,mpopt);
After running this, I got the warning message ‘ CPF TERMINATION: Base case 
power flow did not converge.’
Then I decreased the size of cpf step, but still got the same warning.
Could you please suggest me how should I fix it? And I have attached the 
FourAreaNetwork case file.
Thanks in advance!
Best regards,
Cynthia
  --_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_ Content-Type: 
text/html; charset="utf-8" Content-ID: 
<8f94c2354585e4468b909975c5f41...@namprd08.prod.outlook.com<mailto:8f94c2354585e4468b909975c5f41...@namprd08.prod.outlook.com>>
 Content-Transfer-Encoding: base64  




Hi all,

I am trying to analyse the 
influence of topology changes (like disconnect branches) on system voltage 
stability using the following code:




define_constants;

 

mpc =loadcase('FourAreaNetwork');  "
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "wrong # args: should be "set varName 
?newValue?" load basecase



mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1]; " OutmailID: 123739522, List: 
'matpower-l', MemberID: 84159315 SCRIPT: "change branch 
status



mpopt = 
mpoption('out.all',0,'verbose',2,'out.bus',1); 
mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05); 


mpct = mpc;       
   " TCL MERGE ERROR ( 07/11/2019 14:30:28 ): "invalid command name 
"change" set up target case with basecase
mpct.gen(:,[PG QG]) = mpc.gen(:,[PG 
QG])*2
mpct.bus(:,[PD QD]) = mpc.bus(:,[PD 
QD])*2
results = runcpf(mpc, 
mpct,mpopt);


After running this, I got the warning 
message ‘ CPF TERMINATION: Base case
power flow did not converge.’
Then I decreased the size of cpf 
step, but still got the same warning.


Could you please suggest me 
how should I fix it? And I have attached the FourAreaNetwork
case file.


Thanks in advance!


Best regards,
Cynthia















--_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_--

--_004_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_
Content-Type: application/octet-stream; name="FourAreaNetwork.m"
Content-Description: FourAreaNetwork.m
Content-Disposition: attachment; filename=FourAreaNetwork.m; size=2432;
creation-date="Thu, 11 Jul 2019 17:53:49 GMT";
modification-date="Thu, 11 Jul 2019 17:53:49 GMT"
Content-ID: 
<0847624d7891e14eaaca0c3b07854...@namprd08.prod.outlook.com<mailto:0847624d7891e14eaaca0c3b07854...@namprd08.prod.outlook.com>>
Content-Transfer-Encoding: base64

ZnVuY3Rpb24gbXBjID0gRm91ckFyZWFOZXR3b3JrCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQptcGMu
dmVyc2lvbiA9ICcyJzsJCQkJCQkJCQkJCQkJCQkJCQkJCQkNCm1wYy5iYXNlTVZBID0gMTAwOwkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQ0KDQolJSBCdXMgRGF0YQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ0K
JQlidXNfaQl0eXBlCVBkCVFkCUdzCUJzCWFyZWEJVm0JVmEJYmFzZUtWCXpvbmUJVm1heAlWbWlu
CQkJCQkJCQkNCm1wYy5idXMgPSBbCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQogICAgMSAgIAkyICAg
CTAJMAkwCTAJMQkxCTAJMjIJMQkxLjA1CTAuOTU7DQogICAgMiAgIAkxICAgCTI4MDAJMAkwCTAJ
MQkxCTAJNDAwCTEJMS4wNQkwLjk1Ow0KICAgIDMgICAJMSAgIAkxNzAwCTAJMAkwCTEJMQkwCTQw
MAkxCTEuMDUJMC45NTsNCiAgICA0ICAgCTIgICAJMAkwCTAJMAkxCTEJMAkyMgkxCTEuMDUJMC45
NTsNCiAg

Re: CPF power flow did not converge

[Abhyankar, Shrirang G]

Cynthia,
   Please see this MATPOWER  FAQ<https://matpower.org/doc/faq/#pfconvergence> 
on debugging power flow divergence. Also, you forgot to attach your case file.

Thanks,
Shri


From:  on behalf of W Ruoyu 

Reply-To: MATPOWER discussion forum 
Date: Thursday, July 11, 2019 at 10:54 AM
To: "MATPOWER-L@cornell.edu" 
Subject: CPF power flow did not converge

Hi all,

I am trying to analyse the influence of topology changes (like disconnect 
branches) on system voltage stability using the following code:

define_constants;



mpc =loadcase('FourAreaNetwork');   "
OutmailID: 123739424, List: 'matpower-l', MemberID: 83373175
SCRIPT: "load basecase
mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1];"
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "invalid command name 
"0,0,1,0,1,1,1,1,1,1"change branch status

mpopt = mpoption('out.all',0,'verbose',2,'out.bus',1);
mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05);
mpct = mpc;  "
OutmailID: 123739424, List: 'matpower-l', MemberID: 83373175
SCRIPT: "set up target case with basecase
mpct.gen(:,[PG QG]) = mpc.gen(:,[PG QG])*2
mpct.bus(:,[PD QD]) = mpc.bus(:,[PD QD])*2
results = runcpf(mpc, mpct,mpopt);
After running this, I got the warning message ‘ CPF TERMINATION: Base case 
power flow did not converge.’
Then I decreased the size of cpf step, but still got the same warning.
Could you please suggest me how should I fix it? And I have attached the 
FourAreaNetwork case file.
Thanks in advance!
Best regards,
Cynthia
  --_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_ Content-Type: 
text/html; charset="utf-8" Content-ID: 
<8f94c2354585e4468b909975c5f41...@namprd08.prod.outlook.com<mailto:8f94c2354585e4468b909975c5f41...@namprd08.prod.outlook.com>>
 Content-Transfer-Encoding: base64  




Hi all,

I am trying to analyse the 
influence of topology changes (like disconnect branches) on system voltage 
stability using the following code:




define_constants;

 

mpc =loadcase('FourAreaNetwork');  "
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "wrong # args: should be "set varName 
?newValue?" load basecase



mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1]; "
OutmailID: 123739522, List: 'matpower-l', MemberID: 82861091
SCRIPT: "change branch status
 
 
 
 mpopt = 
mpoption('out.all',0,'verbose',2,'out.bus',1); 
 mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05); 
 
 
 mpct = mpc; 
         "
TCL MERGE ERROR ( 07/11/2019 14:30:28 ): "invalid command name "change" set up 
target case with basecase
mpct.gen(:,[PG QG]) = mpc.gen(:,[PG 
QG])*2
mpct.bus(:,[PD QD]) = mpc.bus(:,[PD 
QD])*2
results = runcpf(mpc, 
mpct,mpopt);


After running this, I got the warning 
message ‘ CPF TERMINATION: Base case
power flow did not converge.’
Then I decreased the size of cpf 
step, but still got the same warning.


Could you please suggest me 
how should I fix it? And I have attached the FourAreaNetwork
case file.


Thanks in advance!


Best regards,
Cynthia















--_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_--

--_004_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_
Content-Type: application/octet-stream; name="FourAreaNetwork.m"
Content-Description: FourAreaNetwork.m
Content-Disposition: attachment; filename=FourAreaNetwork.m; size=2432;
creation-date="Thu, 11 Jul 2019 17:53:49 GMT";
modification-date="Thu, 11 Jul 2019 17:53:49 GMT"
Content-ID: 
<0847624d7891e14eaaca0c3b07854...@namprd08.prod.outlook.com<mailto:0847624d7891e14eaaca0c3b07854...@namprd08.prod.outlook.com>>
Content-Transfer-Encoding: base64

ZnVuY3Rpb24gbXBjID0gRm91ckFyZWFOZXR3b3JrCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQptcGMu
dmVyc2lvbiA9ICcyJzsJCQkJCQkJCQkJCQkJCQkJCQkJCQkNCm1wYy5iYXNlTVZBID0gMTAwOwkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQ0KDQolJSBCdXMgRGF0YQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ0K
JQlidXNfaQl0eXBlCVBkCVFkCUdzCUJzCWFyZWEJVm0JVmEJYmFzZUtWCXpvbmUJVm1heAlWbWlu
CQkJCQkJCQkNCm1wYy5idXMgPSBbCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQogICAgMSAgIAkyICAg
CTAJMAkwCTAJMQkxCTAJMjIJMQkxLjA1CTAuOTU7DQogICAgMiAgIAkxICAgCTI4MDAJMAkwCTAJ
MQkxCTAJNDAwCTEJMS4wNQkwLjk1Ow0KICAgIDMgICAJMSAgIAkxNzAwCTAJMAkwCTEJMQkwCTQw
MAkxCTEuMDUJMC45NTsNCiAgICA0ICAgCTIgICAJMAkwCTAJMAkxCTEJMAkyMgkxCTEuMDUJMC45
NTsNCiAgICA1ICAgCTIgICAJMAkwCTAJMAkxCTEJMAkxMy44CTEJMS4wNQkwLjk1Ow0KICAgIDYg
ICAJMSAgIAkxMzAwCTAJMAkwCTEJMQkwCTQwMAkxCTEuMDUJMC45NTsNCiAgICA3ICAgCTEgICAJ
MTcwMAkwCTAJMAkxCTEJMAk0MDAJMQkxLjA1CTAuOTU7DQogICAgOCAgIAkzICAgCTAJMAkwCTAJ
MQkxCTAJMTMuOAkxCTEuMDUJMC45NTsJCQkJCQkJCQ0KXTsJCQkJCQkJCQkJCQkJCQkJCQkJCQkN
CiUlIEdlbmVyYXRvciBEYXRhCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQolCWJ1cwlQZwlRZwlRbWF4
CVFtaW4JVmcJbUJhc2UJc3RhdHVzCVBtYXgJUG1pbglQ

CPF power flow did not converge

[W Ruoyu]

Hi all,

I am trying to analyse the influence of topology changes (like disconnect 
branches) on system voltage stability using the following code:

define_constants;



mpc =loadcase('FourAreaNetwork');   "
OutmailID: 123739424, List: 'matpower-l', MemberID: 82861091
SCRIPT: "load basecase
 
 mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1];"
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "invalid command name 
"0,0,1,0,1,1,1,1,1,1"change branch status

mpopt = mpoption('out.all',0,'verbose',2,'out.bus',1);
mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05);
mpct = mpc;  "
OutmailID: 123739424, List: 'matpower-l', MemberID: 82861091
SCRIPT: "set up target case with basecase
 mpct.gen(:,[PG QG]) = mpc.gen(:,[PG QG])*2
 mpct.bus(:,[PD QD]) = mpc.bus(:,[PD QD])*2
 results = runcpf(mpc, mpct,mpopt);
 
 After running this, I got the warning message ‘ CPF TERMINATION: Base case 
power flow did not converge.’
 Then I decreased the size of cpf step, but still got the same warning.
 
 Could you please suggest me how should I fix it? And I have attached the 
FourAreaNetwork case file.
 
 Thanks in advance!
 
 Best regards,
 Cynthia
 
 
  --_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_ Content-Type: 
text/html; charset="utf-8" Content-ID: 
<8f94c2354585e4468b909975c5f41...@namprd08.prod.outlook.com> 
Content-Transfer-Encoding: base64  
 
 
 
 
 Hi 
all,
 
 I am trying to analyse the 
influence of topology changes (like disconnect branches) on system voltage 
stability using the following code:
 
 
 
 
 define_constants;
 
  
 
 mpc 
=loadcase('FourAreaNetwork');  "
TCL MERGE ERROR ( 07/11/2019 13:54:03 ): "wrong # args: should be "set varName 
?newValue?" load basecase



mac.branch(:,11)=[0,0,1,0,1,1,1,1,1,1]; %%change branch 
status



mpopt = 
mpoption('out.all',0,'verbose',2,'out.bus',1); 
mpopt=mpoption(mpopt,'cpf.stop_at','NOSE','cpf.step',0.05); 


mpct = mpc;       
   %% set up target case with basecase
mpct.gen(:,[PG QG]) = mpc.gen(:,[PG 
QG])*2
mpct.bus(:,[PD QD]) = mpc.bus(:,[PD 
QD])*2
results = runcpf(mpc, 
mpct,mpopt);


After running this, I got the warning 
message ‘ CPF TERMINATION: Base case
 power flow did not converge.’
Then I decreased the size of cpf 
step, but still got the same warning.


Could you please suggest me 
how should I fix it? And I have attached the FourAreaNetwork
 case file.


Thanks in advance!


Best regards,
Cynthia















--_000_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_--

--_004_CY4PR08MB2808DEF11DE25F2332D96BACDFF30CY4PR08MB2808namp_
Content-Type: application/octet-stream; name="FourAreaNetwork.m"
Content-Description: FourAreaNetwork.m
Content-Disposition: attachment; filename=FourAreaNetwork.m; size=2432;
creation-date="Thu, 11 Jul 2019 17:53:49 GMT";
modification-date="Thu, 11 Jul 2019 17:53:49 GMT"
Content-ID: <0847624d7891e14eaaca0c3b07854...@namprd08.prod.outlook.com>
Content-Transfer-Encoding: base64

ZnVuY3Rpb24gbXBjID0gRm91ckFyZWFOZXR3b3JrCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQptcGMu
dmVyc2lvbiA9ICcyJzsJCQkJCQkJCQkJCQkJCQkJCQkJCQkNCm1wYy5iYXNlTVZBID0gMTAwOwkJ
CQkJCQkJCQkJCQkJCQkJCQkJCQ0KDQolJSBCdXMgRGF0YQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ0K
JQlidXNfaQl0eXBlCVBkCVFkCUdzCUJzCWFyZWEJVm0JVmEJYmFzZUtWCXpvbmUJVm1heAlWbWlu
CQkJCQkJCQkNCm1wYy5idXMgPSBbCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQogICAgMSAgIAkyICAg
CTAJMAkwCTAJMQkxCTAJMjIJMQkxLjA1CTAuOTU7DQogICAgMiAgIAkxICAgCTI4MDAJMAkwCTAJ
MQkxCTAJNDAwCTEJMS4wNQkwLjk1Ow0KICAgIDMgICAJMSAgIAkxNzAwCTAJMAkwCTEJMQkwCTQw
MAkxCTEuMDUJMC45NTsNCiAgICA0ICAgCTIgICAJMAkwCTAJMAkxCTEJMAkyMgkxCTEuMDUJMC45
NTsNCiAgICA1ICAgCTIgICAJMAkwCTAJMAkxCTEJMAkxMy44CTEJMS4wNQkwLjk1Ow0KICAgIDYg
ICAJMSAgIAkxMzAwCTAJMAkwCTEJMQkwCTQwMAkxCTEuMDUJMC45NTsNCiAgICA3ICAgCTEgICAJ
MTcwMAkwCTAJMAkxCTEJMAk0MDAJMQkxLjA1CTAuOTU7DQogICAgOCAgIAkzICAgCTAJMAkwCTAJ
MQkxCTAJMTMuOAkxCTEuMDUJMC45NTsJCQkJCQkJCQ0KXTsJCQkJCQkJCQkJCQkJCQkJCQkJCQkN
CiUlIEdlbmVyYXRvciBEYXRhCQkJCQkJCQkJCQkJCQkJCQkJCQkJDQolCWJ1cwlQZwlRZwlRbWF4
CVFtaW4JVmcJbUJhc2UJc3RhdHVzCVBtYXgJUG1pbglQYzEJUGMyCVFjMW1pbglRYzFtYXgJUWMy
bWluCVFjMm1heAlyYW1wX2FnYwlyYW1wXzEwCXJhbXBfMzAJcmFtcF9xCWFwZg0KbXBjLmdlbiA9
IFsJCQkJCQkJCQkJCQkJCQkJCQkJCQkNCiAgICAxCTE3NDAJMAkxMjYzCS0xMjYzCTEJMTAwCTEJ
MjYwOC4yCTAJMAkwCTAJMAkwCTAJMAkwCTAJMAkwOw0KICAgIDQJMTgwMAkwCTEyNjMJLTEyNjMJ
MQkxMDAJMQkyNjA4LjIJMAkwCTAJMAkwCTAJMAkwCTAJMAkwCTA7DQogICAgNQkxOTYwCTAJMTE0
Mi4wMwktMTE0Mi4wMwkxCTEwMAkxCTIzNTgJMAkwCTAJMAkwCTAJMAkwCTAJMAkwCTA7DQogICAg
OAkyMDE5CTAJMTI1Ni4yMwktMTI1Ni4yMwkxCTEwMAkxCTI1OTMuOAkwCTAJMAkwCTAJMAkwCTAJ
MAkwCTAJMDsNCl07CQkJCQkJCQkJCQkJCQkJCQkJCQkJDQolJSBUcmFuc21pc3Npb24gTGluZXMg
RGF0YQkJCQkJCQkJCQkJCQkJCQkJCQkJCQ0KJQlmYnVzCXRidXMJcgl4CWIJcmF0ZUEJcmF0ZUIJ
cmF0ZUMJcmF0aW8JYW5nbGUJc3RhdHVzCWF

Re: Question about power flow for a system with faulted bus

[Abhyankar, Shrirang G]

During faulted condition, the bus voltages are dictated by the fault impedance 
(and the system conditions). As such, CPF will not help here.

Shri


From:  on behalf of Ismael K 
Abdulrahman 
Reply-To: MATPOWER discussion forum 
Date: Saturday, June 1, 2019 at 8:03 AM
To: MATPOWER discussion forum 
Subject: Re: Question about power flow for a system with faulted bus

Thanks Shri for your reply and the nice trick you mentioned; I never thought 
about it.

How about using continuation power flow instead of a regular power flow? Is it 
possible to use it for this kind of problem? As you know, CPF is widely used to 
solve low voltage problem. Any idea?

Thank you once again.
Ismael



On Jun 1, 2019, at 7:38 AM, Abhyankar, Shrirang G 
mailto:shrirang.abhyan...@pnnl.gov>> wrote:
Ismael,
   Power flow with loads modeled as “constant power” faces convergence issue 
when the voltages are low. A common trick is to convert constant power loads to 
constant impedance loads for low voltages. In MATPOWER, you can convert all the 
loads to constant impedance using the options 'exp.sys_wide_zip_loads.pw' (real 
power) and 'exp.sys_wide_zip_loads.qw'. Here, pw and qw are fractions of 
constant power, constant current, and constant impedance load composition. For 
a constant impedance only load the fractions should be [0,0,1].

Shri



From: 
mailto:bounce-123652900-83373...@list.cornell.edu>>
 on behalf of Ismael K Abdulrahman 
mailto:ikabdulra...@students.tntech.edu>>
Reply-To: MATPOWER discussion forum 
mailto:matpowe...@list.cornell.edu>>
Date: Saturday, June 1, 2019 at 1:17 AM
To: "matpower-l@cornell.edu<mailto:matpower-l@cornell.edu>" 
mailto:matpower-l@cornell.edu>>
Subject: Question about power flow for a system with faulted bus


Dear Matpower community,



I am a Ph.D. student working in power system dynamic analysis. I use Matpower 
for computing the initial values of the system variables.

I want to find the initial values of the algebraic variables (voltage 
magnitude, voltage angle, generator current phasors...)  at the time of 
disturbance. The disturbance is a three phase fault at one bus in the system, 
usually a load or zero-injection bus. I tried to consider the faulted bus as a 
generator with zero power and zero voltage, but the problem cannot be solved. I 
was wondering if there is any way to get around this problem? I greatly 
appreciate your help.



Thanks in advance

Ismael

Re: Question about power flow for a system with faulted bus

[Ismael K Abdulrahman]

Thanks Shri for your reply and the nice trick you mentioned; I never thought 
about it.

How about using continuation power flow instead of a regular power flow? Is it 
possible to use it for this kind of problem? As you know, CPF is widely used to 
solve low voltage problem. Any idea?

Thank you once again.
Ismael



On Jun 1, 2019, at 7:38 AM, Abhyankar, Shrirang G 
mailto:shrirang.abhyan...@pnnl.gov>> wrote:

Ismael,
   Power flow with loads modeled as “constant power” faces convergence issue 
when the voltages are low. A common trick is to convert constant power loads to 
constant impedance loads for low voltages. In MATPOWER, you can convert all the 
loads to constant impedance using the options 'exp.sys_wide_zip_loads.pw' (real 
power) and 'exp.sys_wide_zip_loads.qw'. Here, pw and qw are fractions of 
constant power, constant current, and constant impedance load composition. For 
a constant impedance only load the fractions should be [0,0,1].

Shri



From: 
mailto:bounce-123652900-83373...@list.cornell.edu>>
 on behalf of Ismael K Abdulrahman 
mailto:ikabdulra...@students.tntech.edu>>
Reply-To: MATPOWER discussion forum 
mailto:matpowe...@list.cornell.edu>>
Date: Saturday, June 1, 2019 at 1:17 AM
To: "matpower-l@cornell.edu<mailto:matpower-l@cornell.edu>" 
mailto:matpower-l@cornell.edu>>
Subject: Question about power flow for a system with faulted bus


Dear Matpower community,



I am a Ph.D. student working in power system dynamic analysis. I use Matpower 
for computing the initial values of the system variables.

I want to find the initial values of the algebraic variables (voltage 
magnitude, voltage angle, generator current phasors...)  at the time of 
disturbance. The disturbance is a three phase fault at one bus in the system, 
usually a load or zero-injection bus. I tried to consider the faulted bus as a 
generator with zero power and zero voltage, but the problem cannot be solved. I 
was wondering if there is any way to get around this problem? I greatly 
appreciate your help.



Thanks in advance

Ismael

Re: Question about power flow for a system with faulted bus

[Abhyankar, Shrirang G]

Ismael,
   Power flow with loads modeled as “constant power” faces convergence issue 
when the voltages are low. A common trick is to convert constant power loads to 
constant impedance loads for low voltages. In MATPOWER, you can convert all the 
loads to constant impedance using the options 'exp.sys_wide_zip_loads.pw' (real 
power) and 'exp.sys_wide_zip_loads.qw'. Here, pw and qw are fractions of 
constant power, constant current, and constant impedance load composition. For 
a constant impedance only load the fractions should be [0,0,1].

Shri



From:  on behalf of Ismael K 
Abdulrahman 
Reply-To: MATPOWER discussion forum 
Date: Saturday, June 1, 2019 at 1:17 AM
To: "matpower-l@cornell.edu" 
Subject: Question about power flow for a system with faulted bus


Dear Matpower community,



I am a Ph.D. student working in power system dynamic analysis. I use Matpower 
for computing the initial values of the system variables.

I want to find the initial values of the algebraic variables (voltage 
magnitude, voltage angle, generator current phasors...)  at the time of 
disturbance. The disturbance is a three phase fault at one bus in the system, 
usually a load or zero-injection bus. I tried to consider the faulted bus as a 
generator with zero power and zero voltage, but the problem cannot be solved. I 
was wondering if there is any way to get around this problem? I greatly 
appreciate your help.



Thanks in advance

Ismael

Question about power flow for a system with faulted bus

[Ismael K Abdulrahman]

Dear Matpower community,


I am a Ph.D. student working in power system dynamic analysis. I use Matpower 
for computing the initial values of the system variables.

I want to find the initial values of the algebraic variables (voltage 
magnitude, voltage angle, generator current phasors...)  at the time of 
disturbance. The disturbance is a three phase fault at one bus in the system, 
usually a load or zero-injection bus. I tried to consider the faulted bus as a 
generator with zero power and zero voltage, but the problem cannot be solved. I 
was wondering if there is any way to get around this problem? I greatly 
appreciate your help.


Thanks in advance

Ismael

Solving Power Flow with Node Breaker Model

[NEERAJ NAYAK]

All - Does anybody has experience solving power flow with node breaker
model in matpower? Any ideas or suggestions?

Thanks!

Neeraj

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
>
>

power flow with forward backward sweep algorithm for radial system

[amir ali Hosseini]

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: Isolated Bus - Power flow solution

[Abhyankar, Shrirang G]

John,
   MATPOWER’s power flow does not do a topology check to find isolated buses 
and islands. So, any isolated bus i needs to have its bus type set to None (4) 
-- mpc.bus(i, BUS_TYPE) = 4. If you want to find out which buses get isolated 
when the status of one or more lines changes then use the routines 
case_info()<http://www.pserc.cornell.edu/matpower/docs/ref/matpower5.0/case_info.html>
 or 
find_islands()<http://www.pserc.cornell.edu/matpower/docs/ref/matpower5.0/find_islands.html>.

Shri
From:  on behalf of John Cynn 

Reply-To: MATPOWER discussion forum 
Date: Sunday, April 28, 2019 at 9:39 AM
To: "MATPOWER-L@cornell.edu" 
Subject: Isolated Bus - Power flow solution

Hi All,

I had a question regarding matpower solution when a bus might get isolated. For 
example, changing the status of a line or lines causes a bus to be 
isolated/islanded. I think the power flow does not converge when such scenario 
occurs. Is there a way to handle this automatically and change bus status to 
isolated? Any suggestions on handling islands?

Thanks.
John

Isolated Bus - Power flow solution

[John Cynn]

Hi All,

I had a question regarding matpower solution when a bus might get isolated.
For example, changing the status of a line or lines causes a bus to be
isolated/islanded. I think the power flow does not converge when such
scenario occurs. Is there a way to handle this automatically and change bus
status to isolated? Any suggestions on handling islands?

Thanks.
John