Thanks, Shri. I think that’s a good solution. Initially I was thinking that
approach wouldn’t work because my system was not even generating that warning
(which surprised me). I just went to re-run the example to confirm that I
hadn’t just missed it and discovered that somewhere in my MATPOWER tests, that
warning is getting disabled (intentionally) but not re-enabled (a bug). So when
I was doing my testing of this issue yesterday, I was doing it in a Matlab
session that I’d previously used to run MATPOWER tests, which had left that
warning disabled.
I’ll have to see if I can track down where that is happening and fix it.
Ray
> On Mar 23, 2015, at 7:13 PM, Abhyankar, Shrirang G. <[email protected]>
> wrote:
>
>
>
> From: Ray Zimmerman <[email protected] <mailto:[email protected]>>
> Reply-To: MATPOWER discussion forum <[email protected]
> <mailto:[email protected]>>
> Date: Monday, March 23, 2015 at 1:49 PM
> To: MATPOWER discussion forum <[email protected]
> <mailto:[email protected]>>
> Subject: Re: Blackout in the USA - Islands VS Whole System
>
> Well, conceptually, no I’m afraid it doesn’t answer my question. For example,
> suppose you have a system with a single slack bus and you open several lines
> and create an island with more load than generation, with no slack bus. How
> is it possible for a DC power flow to converge* to any meaningful answer? A
> set of voltage angles that satisfies the DC power balance equations does not
> exist.
>
> However, in trying some examples to verify my understanding, I see that see
> that MATPOWER happily returns success = 1 for some such cases, sometimes
> without Matlab even issuing any warning of a singular matrix. Some of the
> voltage angles are obviously garbage (extremely large), but one may not think
> to check that. So, I see a potential source for the confusion on this.
>
> I had assumed that Matlab would complain about a singular matrix in these
> cases, but it seems that maybe I need to add an explicit check to the DC
> power flow to set the success flag to zero in such cases. Hmmm, wonder what’s
> the most reliable inexpensive check I can do?
>
> See below for a fun example ...
>
> Ray
>
> * By the way, the DC power flow is computed directly by solving a linear
> system of equations, not by some iterative numerical algorithm, so
> “converging” isn’t really the correct term.
>
>
> Example:
>
> mpc = loadcase('case30');
> mpc.branch([15; 25; 26; 32], BR_STATUS) = 0;
> r = rundcpf(mpc);
> case_info(r)
>
> I get a ‘Matrix is singular to working precision’ warning on running the DC
> power flow.
>
> MATPOWER Version 5.1, 20-Mar-2015 -- DC Power Flow
> Warning: Matrix is singular to working precision.
> > In dcpf at 27
> In runpf at 142
> In rundcpf at 74
>
> Converged in 0.27 seconds
> ================================================================================
> | System Summary
> |
> ================================================================================
>
> How many? How much? P (MW) Q (MVAr)
> --------------------- ------------------- ------------- ————————
> …. Followed by the rest of the system summary log…..
>
> Unfortunately, MATLAB just throws a warning which gets flushed away on the
> screen by the summary logs. The warning, not being an exception, is not
> caught which fools MATPOWER to think that is a good solution. I think for
> linear problems this warning needs to be trapped and converted into an
> exception that can then be used for setting the success flag. One possible
> way is to add
> warning('error','MATLAB:singularMatrix’); at the beginning of rundcpf(). This
> would throw an exception when MATLAB issues a ‘Matrix is singular warning’.
> One can then put the linear solve in dcpf in a try catch block and set the
> success flag when there an exception is thrown. Note that dcpf also needs to
> return a success flag. Currently, it only returns the voltage angle vector.
>
> Shri
>
>
> Hmmm, there’s an island, but everything looks fine … generation and load in
> the island-without-slack even match! Must be that case30 is already a solved
> DC PF case.
>
> mpc.gen(6, PG) = 0;
> r = rundcpf(mpc);
>
> Ok, now, no errors or singular matrix warnings, but we have voltages angles
> upwards of 1e15 and load and generation in island do *NOT* match. Putting a
> breakpoint in dcpf.m shows that the matrix being factored has a condition
> number near 1e17 … i.e. it really is singular.
>
>
>
>> On Mar 23, 2015, at 12:16 PM, Bijay Hughes <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> AC powerflow has convergence problem in many scenarios which we all know.
>> The DC powerflow converges for the whole system even if this system has one
>> or many islands; however, if a system contains one or many islands the AC
>> powerflow does not converge. Does this answer your question?
>>
>> On Mon, Mar 23, 2015 at 11:44 PM, Ray Zimmerman <[email protected]
>> <mailto:[email protected]>> wrote:
>> I don’t understand approach (1). I don’t know why you say that DC power flow
>> implies you don’t have to keep track of islanding. How does the AC or DC
>> power flow make a difference here?
>>
>> Ray
>>
>>
>> > On Mar 20, 2015, at 6:08 AM, Bijay Hughes <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > Hej all,
>> >
>> > I am modeling blackout in the US transmission lines system, and have two
>> > approaches to do so. I do it with DC power flow, which means I don't need
>> > to take care of islanding if I don't want to (although I am aware that I
>> > need to take care of isolated buses for convergence reasons). I have two
>> > approaches to do so: (1) do cascading failure simulation on whole system
>> > each iteration, whereby one doesn't keep track of islands; (2) do
>> > cascading failure simulation on the whole system to begin, see if islands
>> > are formed, and run the same simulation on each of these islands, and
>> > repeat the process exhaustively. In both cases, the powerflow converges as
>> > it is DC flow. However, the results are not matching, and I am wondering
>> > why. Could it be because of the difference in the number of slack buses?
>> > Because in my approach (1) the system will only have one slack bus in each
>> > iteration, however in my approach (2) the system will have multiple slack
>> > buses as the matpower chooses slack buses for each island automatically,
>> > thereby my system as a whole will have multiple slack buses. Is this the
>> > only reason? Which approach is better, (1) or (2)?
>> >
>> > Best,
>> >
>> > BH
>>
>>
>>
>>
>