up on the FAQ.
>>
>> Thanks,
>> Shri
>>
>> From: Jose Luis Marin
>> Reply-To: MATPOWER discussion forum
>> Date: Wednesday, August 12, 2015 at 2:42 AM
>> To: MATPOWER discussion forum
>> Subject: Re: convergence problem in runpf.
>>
>&
have your steps up on the
>> FAQ.
>>
>> Thanks,
>> Shri
>>
>> From: Jose Luis Marin mailto:mari...@gridquant.com>>
>> Reply-To: MATPOWER discussion forum > <mailto:matpowe...@list.cornell.edu>>
>> Date: Wednesday, August 1
lto:matpowe...@list.cornell.edu>>
Date: Wednesday, August 12, 2015 at 2:42 AM
To: MATPOWER discussion forum
mailto:matpowe...@list.cornell.edu>>
Subject: Re: convergence problem in runpf.
Mirish,
I couldn't help notice that you're building this model from scratch (well, from
a databa
ive. It’ll be good
> to have your steps up on the FAQ.
>
> Thanks,
> Shri
>
> From: Jose Luis Marin
> Reply-To: MATPOWER discussion forum
> Date: Wednesday, August 12, 2015 at 2:42 AM
> To: MATPOWER discussion forum
> Subject: Re: convergence problem in runpf.
>
&
t 2:42 AM
To: MATPOWER discussion forum
mailto:matpowe...@list.cornell.edu>>
Subject: Re: convergence problem in runpf.
Mirish,
I couldn't help notice that you're building this model from scratch (well, from
a database) and you mentioned "To make the problem simple I used
e done via results =
>>> runcpf(mpcbase,mpctarget,mpoption(‘cpf.stop_at’,’NOSE’)). If
>>>results.cpf.max_lam is >= 1, then it shows that the initial guess for the
>>>power flow is the problem for its divergence. To obtain a ‘good’ initial
>>>guess,
it to stop exactly at
>>lam = 1 (the target case loading and generation) via results =
>>runcpf(mpcbase,mpctarget,mpoption(‘cpf.stop_at’,1.0)). You can then save
>>the results struct as a matpower case file (via savecase()). On the other
>>hand, if results.cpf.
ll.edu>>
Date: Tuesday, August 11, 2015 at 7:36 PM
To: MATPOWER discussion forum
mailto:matpowe...@list.cornell.edu>>
Subject: Re: convergence problem in runpf.
Dear Mr.Shree,
Thank you very much for your help. As per your suggestion and FAQ I tried to
find out the problems.
The resu
as a matpower case file (via savecase()). On the other
>hand, if results.cpf.max_lam < 1, then the loading/generation in your
>original case is beyond the system steady-state loading limit.
>
> Shri
> From: Mirish Thakur
> Reply-To: MATPOWER discussion forum
> Date: Mo
ATPOWER discussion forum
mailto:matpowe...@list.cornell.edu>>
Subject: convergence problem in runpf.
Dear Matpower Community,
I’m working on power flow project and have used grid data from database. I have
modelled all line parameters (R X B) in p.u. system, also same for transformers
a
Dear Matpower Community,
I’m working on power flow project and have used grid data from database. I
have modelled all line parameters (R X B) in p.u. system, also same for
transformers and kept generator output until it satisfies active and
reactive power demand. For renewable generation, I spec
Dear Jose L. Marin and Dr.Zimmerman,
Thank you Mr.Jose L. Marin for your detailed explanations. I also thank
Dr.Zimmerman for giving hint in using find_islands() function.
Regards,
Babulal
On 31-10-2014 18:15, Jose Luis Marin wrote:
> Hello Babulal,
>
> I believe that the problem is t
Hello Babulal,
I believe that the problem is that MATPOWER does not automatically remove
islands when running a powerflow. Each of the three contingencies you list
happen to isolate a bus, therefore the network needs to be reduced prior to
the call to runpf (Ray -- please correct me if I'm wrong)
Dear Dr.Zimmerman,
When I perform the power flow for the following contingency in
case_ieee30.m system, MATPOWER experiences numerical instability.
1. Line number 13 (Connected between buses 9-11)
2. Line number 16 (Connected between buses 13-12)
3. Line number 34 (Connected between buses 25-
14 matches
Mail list logo
