What Shri says is almost correct. It will mark the bus as being out of service, 
but it must also be disconnected by setting the BR_STATUS any connected 
branches to 0 as well.

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




On Apr 25, 2013, at 10:21 AM, Shri <[email protected]> wrote:

> 
> On Apr 25, 2013, at 7:34 AM, Hendrik Acker wrote:
> 
>> Dear Mr. Zimmerman,
>> what do you mean by setting the Bus_type to none? I thought the bus type  
>> has to be a 1-digit between 0 and 3.
>  Bus_type is a single digit between 1 and 4. Setting the bus_type = 4 (NONE) 
> will make the bus out of service. 
>> As  Ashwin, I too, would like to know how to disable/turn off a bus without 
>> having to remove it from the model-file.
>>  
>> Best regards
>> Hendrik Acker
>>  
>> Von: [email protected] 
>> [mailto:[email protected]]Im Auftrag von Ray 
>> Zimmerman
>> Gesendet: Montag, 22. April 2013 22:35
>> An: MATPOWER discussion forum
>> Betreff: Re: re; problem with matpower- removing the bus from network
>>  
>> Are you saying that MATPOWER is incorrectly reporting the total load served? 
>>  Hmmm, yes, it looks like that is true. That would be a bug. I will make a 
>> note and plan to include a fix in the next version. Thanks for catching that.
>>  
>> -- 
>> Ray Zimmerman
>> Senior Research Associate
>> 419A Warren Hall, Cornell University, Ithaca, NY 14853
>> phone: (607) 255-9645
>> 
>> 
>> 
>> 
>>  
>> On Apr 22, 2013, at 4:28 PM, Ashwin Venkataramanan <[email protected]> wrote:
>> 
>> 
>> Dear Dr ZImmerman
>>  
>> I have rectified the above problem.
>> But now when i remove the bus or substation there is some load i will not be 
>> able to supply.
>> I am not able to get the value of load being supplied by the system after 
>> removing the buses.
>> That value is not getting updated. Is there any fix to this? 
>>  
>> Best Regards
>> Ashwin Venkataramanan
>>  
>> 
>> On Mon, Apr 22, 2013 at 1:19 PM, Ray Zimmerman <[email protected]> wrote:
>> 1) Make sure that when you isolate a bus you set it's BUS_TYPE to NONE and 
>> that your system still has a REF bus.
>> 2) I'm not sure what you mean, but you can always load the case and make 
>> changes before running it, like …
>>  
>> define_constants;
>> mpc = loadcase('case118');
>> mpc.branch(110, BR_STATUS) = 0;
>> r = runopf(mpc);
>>  
>> -- 
>> Ray Zimmerman
>> Senior Research Associate
>> 419A Warren Hall, Cornell University, Ithaca, NY 14853
>> phone: (607) 255-9645
>> 
>> 
>>  
>> 
>>  
>> On Apr 20, 2013, at 10:53 PM, Ashwin Venkataramanan <[email protected]> wrote:
>> 
>> 
>> Dear Dr.Zimmerman
>> 
>>                I am a graduate student in electrical engineering from 
>> Arizona state university. I have a doubt about opening buses using MATPOWER. 
>> I have two questions.
>> 
>> 1)     My simulation involves removing a substation out of the network and 
>> testing if the power flow converges. Just like first contingency analysis 
>> for substations. Each bus is characterized as a substation or in some cases 
>> combination of 2 buses are classified as substation. I have read the 
>> MATPOWER user manual, from which I find only ways to remove branches and 
>> generator from the network. I have tried the simulation by removing the 
>> branches connected to the bus using the command
>> 
>>                    mpc.branch(110,BR_STATUS)=0;
>> 
>> for removing the branch 110 which may connect two buses. Similarly removing 
>> all the branches connected to a bus in order to isolate a bus. I believe 
>> this approach is right to remove a bus. But my powerflow diverges each time 
>> I remove any bus(or substation). I believe this will not be a case as system 
>> most of time must work for first contingency involving substation. I have 
>> tested my code on both 118 and 30 bus case. Is there any way to remove bus 
>> directly off other than removing using the branches(above mentioned 
>> approach) ?
>> 
>>  2)  Is there any way to do convert the existing “case118.m” to modified 118 
>> bus?
>> 
>>  
>> Best Regards
>> 
>> Ashwin Venkataramanan
>> 
>> Arizona state university
>> 
>>  
>>  
> 

Reply via email to