Dear Dr.Zimmerman

Recently I've found MATPOWER really helpful and read a lot threads in
the mailing list. I kind of overheard the existence of some codes that
detect islanding and divide the system into several cases. Could you
please send me these codes? I would really appreciate that. I am
currently using MATGRAPH to detect islanding in contigencies but it
brings troubles.

Also, I found that in OPF, when I want to clear the voltage limit of
certain bus, I naturally assume that I could get that done by setting
both the upper and lower boundaries to zero. However I found the
result is that the voltage is limited to zero. Is there any way that I
could skip the voltage limit of certain bus? Thank you!



On Fri, Mar 2, 2012 at 2:57 PM, Hua Bowen <[email protected]> wrote:
> Oh, I forgot to consider real and reactive power output limits of
> generators! I thought they were considered in power flow.
>
> The data are from power supply company and they are in a mess. I did
> some modification on the generator constrains to make them reasonable
> and it converged.
>
> Thank you! Your suggestions helped a lot :)
>
> On Fri, Mar 2, 2012 at 12:03 AM, Ray Zimmerman <[email protected]> wrote:
>> I was just thinking that setting the gencosts to zero might cause numerical
>> difficulties for some of the solvers. As far as the power flow solution
>> being a solution to the OPF problem, that is true only if all of the
>> voltages, flows and generator real and reactive dispatches are within limits
>> (which is not guaranteed by the power flow solver).
>>
>> --
>> Ray Zimmerman
>> Senior Research Associate
>> 419A Warren Hall, Cornell University, Ithaca, NY 14853
>> phone: (607) 255-9645
>>
>>
>>
>>
>> On Mar 1, 2012, at 10:12 AM, Hua Bowen wrote:
>>
>> Thank you so much Dr.Zimmerman, for your really detailed reply.
>>
>> First of all, power flow with dispatchable loads works well. I mean,
>> the result is exactly the same with the normal loads situation.  Also,
>> the reason I set the cost for all real generators to zero and the cost
>> for all dummy generators to 1$/MW is that I could get the amount of
>> load shedding directly from the objective function. For the case I am
>> solving now I expect no load shedding, but in reliability evaluation
>> process, if some outage of generators and/or transmission lines
>> happens, I could easily get the load shedding data I want.  Is there
>> any danger caused by setting cost for all real generators to zero?
>>
>> I tried your suggestion, setting voltage limits to 0.9-1.1 (or more
>> relaxed ones) and setting the line limits to zero, also setting low
>> costs for the real generators and high value for dummy ones.
>> Unfortunately that they won't help.
>>
>> I didn't do any change to the system so I would expect that, given
>> that the power flow converges, then at least the OPF problem has a
>> solution which is the same result as the converged power flow. Am I
>> right?
>>
>> Sorry I didn't mention that the real-life system is a really big one
>> in Northwest China, which has buses of different base voltages,
>> varying from 6kV to 800kV. And in the converged power flow, the
>> voltages of some buses are as low as 0.74. (Most of the buses are
>> fine. And the one with the extremely low voltage is not a important
>> bus. I mean, not in the backbone network, and with a low base
>> voltage.) I think the case itself might not be a really good one.
>> I'll see whether I can do some simplification to the system, after all
>> I just want to know the reliability data for the high-voltage
>> transmission network.
>>
>>
>>
>> On Thu, Mar 1, 2012 at 9:33 PM, Ray Zimmerman <[email protected]> wrote:
>>
>> See responses below ...
>>
>>
>> On Mar 1, 2012, at 7:25 AM, Hua Bowen wrote:
>>
>>
>> Dear All,
>>
>>
>> I am dealing with reliability assessment of a real-life system. This
>>
>> system has 5370 nodes. I converted all the loads into dispatchable
>>
>> loads and the power flow converged.
>>
>>
>> I planned to use dispatchable load model to determine the amount of
>>
>> load shedding in different contingencies. So I set the cost for all
>>
>> real generators to zero and the cost for all dummy generators (used to
>>
>> model dispatchable loads) to 1$/MW. However, when I was running AC OPF
>>
>> on this system, using default solver, MATPOWER says that “Matrix is
>>
>> singular” and “Numerically failed”. I tweaked the all the voltage
>>
>> limits to 0.7 p.u. – 1.3 p.u., “Matrix is singular” message
>>
>> disappeared, but OPF still didn’t converge.
>>
>>
>>
>> If no load shedding is required and all generator costs are zero, then the
>>
>> optimization surface is very flat ... i.e. the objective function will be
>>
>> constant no matter what the generator cost. I normally use the actual
>>
>> generator costs for the real generators and some very high value,
>>
>> representing the value of lost load, for the dispatchable loads.
>>
>>
>> Also, I tried MINOPF, TRALM, and even DC OPF, it still won’t converge.
>>
>>
>> I tried to use the result of AC power flow as the initial value for AC
>>
>> OPF, MATPOWER says that "makeAvl: For a dispatchable load, PG and QG
>>
>> must be consistent with the power factor defined by PMIN and the Q
>>
>> limits." I wonder why?
>>
>>
>>
>> Hmmm ... well, the dispatchable load model was designed with only the OPF
>>
>> problem in mind, so it's probably not behaving as expected in the power flow
>>
>> problem. For the power flow, were you setting all of the loads at their
>>
>> nominal values (i.e. PG = PMIN)?
>>
>>
>> My guess is that for (at least some of) the buses with only dispatchable
>>
>> loads, the bus type was set to PV, which means that the power flow will
>>
>> change the QG in order to maintain the voltage setpoint, thus violating the
>>
>> constant power factor constraint. Setting the bus type to PQ for these buses
>>
>> should fix that. Unfortunately, for buses with both generators and
>>
>> dispatchable loads, the power flow computes the correct net QG, but then
>>
>> distributes it evenly across the "generators" (including dispatchable loads)
>>
>> at that bus. So it would also mess up the dispatchable load power factors. I
>>
>> suppose this could be corrected for manually after the fact, but that's not
>>
>> currently in the code (something for my to-do list).
>>
>>
>> Also, many of the solvers select their own starting point anyway. MINOPF is
>>
>> one of the few that attempts to use the starting point you provide.
>>
>> Unfortunately, 5370 buses is pretty big for MINOPF.
>>
>>
>> I checked the branch flow limits. They are quite reasonable. I set
>>
>> voltage limits to all zero. It didn’t help.
>>
>>
>>
>> I would use non-zero gen costs,  keep the voltage limits at something
>>
>> reasonable (0.9-1.1) and try setting the line limits to zero (to disable
>>
>> them) to see if that allows it to converge.
>>
>>
>> I wonder what is wrong. Is my approach to this problem appropriate?
>>
>> Anything wrong with my setting of gencost?
>>
>>
>>
>> I think your approach is fine, except for the zero costs in gencost and the
>>
>> extreme relaxing of the voltage constraints. I think that trying to start
>>
>> with a power flow solution (that respects the constant power factor
>>
>> constraints of the dispatchable loads) is a good idea. Then have a look at
>>
>> the voltages, branch flows, reactive dispatches to see which ones (if any)
>>
>> are violating the OPF constraints.
>>
>>
>> By the way, I wonder whether MATPOWER allows multiple slack buses in
>>
>> AC OPF? In my case I tried both multiple and single slack bus. Won’t
>>
>> help.
>>
>>
>>
>> MATPOWER does allow multiple reference buses in the AC OPF. Keep in mind
>>
>> that for the OPF problem there is no concept of "slack", as in generation
>>
>> balance, only the concept of voltage angle reference. So, I would never use
>>
>> multiple reference buses unless the system is islanded, in which case you
>>
>> want a single reference bus in each island.
>>
>>
>> Hope this helps,
>>
>>
>> --
>>
>> Ray Zimmerman
>>
>> Senior Research Associate
>>
>> 419A Warren Hall, Cornell University, Ithaca, NY 14853
>>
>> phone: (607) 255-9645
>>
>>
>>
>>
>>


Reply via email to