Re: Dealing with reliability assessment using AC OPF
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 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 disabl
Re: Dealing with reliability assessment using AC OPF
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 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 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 = P
Re: Dealing with reliability assessment using AC OPF
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 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 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 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 >
no solution to DC power flow
Dear all, I have a case with more than 5,000 nodes. I wonder why the DC power flow results in meaningless solution (the angle of all nodes turns out to be NaN) while AC power flow has a normal result. Some branches have a reactance as small as 1e-6 p.u. and zero resistance. I thought that make the B matrix ill-conditioned. But even after I changed all those small reactances to 1e-2, the result didn't change. I couldn't figure it out. The case file is included in the attachment. Thank you for your help. function mpc = nwgrid %% 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 1 750 -278.9 0 0 0 1 0 525 0 1.04761905 0.952380952; 3 1 360 -84.49 0 0 0 1 0 363 0 1 0.909090909; 6 1 0 0 0 -300.0003 5 1 0 800 0 1 0.9375; 7 1 0 0 0.1491 -0.95 1 0 1 0 0 0; 8 1 0 0 0 0 5 1 0 800 0 1 0.9375; 9 1 0 0 0 -66.1499911 5 1 0 69.30 1 0.909090909; 10 1 0 0 0 0 5 1 0 230 0 1.05217391 0.956521739; 11 1 0 0 0 -239.999808 5 1 0 800 0 1 0.9375; 12 1 0 0 0 -239.999808 5 1 0 800 0 1 0.9375; 13 1 0 0 0 0 5 1 0 800 0 1 0.9375; 14 1 0 0 0.1491 -0.95 1 0 1 0 0 0; 15 1 0 0 0 0 5 1 0 800 0 1 0.9375; 16 1 0 0 0 0 5 1 0 69.30 1 0.909090909; 17 1 0 0 0 0 5 1 0 230 0 1.05217391 0.956521739; 18 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 19 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 20 1 0 0 0.1491 -0.95 1 0 1 0 0 0; 21 1 0 0 0 0 5 1 0 800 0 1 0.9375; 22 1 0 0 0 -99.2249539 5 1 0 69.30 1 0.909090909; 23 1 0 0 0 0 5 1 0 230 0 1.05217391 0.956521739; 24 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 25 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 26 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 27 1 0 0 0 -300.0003 5 1 0 800 0 1 0.9375; 28 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 29 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 30 1 0 0 0.1491 -0.95 1 0 800 0 1 0.9375; 31 1 0 0 0 0 5 1 0 800 0 1 0.9375; 32 1 0 0 0 0 5 1 0 69.30 1 0.909090909; 33 1 0 0 0 0 5 1 0 230 0 1.05217391 0.956521739; 34 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 35 1 0 0 0 -420.00042 5 1 0 800 0 1 0.9375; 36 1 0 0 0 -300.0003 5 1 0 800 0 1 0.9375; 37 1 0 0 0 -300.0003 5 1 0 800 0 1 0.9375; 38 1 0 0 0.1491 -0.65 1 0 1 0 0 0; 39 1 0 0 0
Re: no solution to DC power flow
Thank you Dr.Zimmerman.
Here's a single slack bus version of the same network. Oddly enough,
the first problem you mentioned still exist.
Also I noticed that the DC power flow in MATPOWER is simply done by
matrix left division. I wonder that DC load flow doesn't need
iteration and why the result is NaN?
On Tue, Mar 13, 2012 at 10:01 PM, Ray Zimmerman wrote:
> Not sure what's going on here, but I wanted to pass on what I've noticed
> initially. Something is strange. Normally the following should produce
> something that converges immediately without iterating at all the second
> time, but in this case it diverges ...
>
> opt = mpoption('OUT_BUS', 0, 'OUT_BRANCH', 0, 'VERBOSE', 2);
> mpc = loadcase('grid');
> r0 = runpf(mpc, opt);
> r = runpf(r0, opt);
>
> I also noticed that there are 3 reference buses even though it is a fully
> connected network (which I assume is an error). When I change two of the
> reference buses to PV buses, the AC PF no longer converges.
>
> Hopefully, this may trigger some ideas for ways to track this down. But, the
> fact that the 2nd run above diverges makes me think I should double-check
> how the code handles cases with multiple reference buses. I probably need
> better error checking somewhere.
>
> --
> Ray Zimmerman
> Senior Research Associate
> 419A Warren Hall, Cornell University, Ithaca, NY 14853
> phone: (607) 255-9645
>
>
>
>
> On Mar 13, 2012, at 4:44 AM, Hua Bowen wrote:
>
> Dear all,
>
> I have a case with more than 5,000 nodes. I wonder why the DC power
> flow results in meaningless solution (the angle of all nodes turns out
> to be NaN) while AC power flow has a normal result. Some branches have
> a reactance as small as 1e-6 p.u. and zero resistance. I thought that
> make the B matrix ill-conditioned. But even after I changed all those
> small reactances to 1e-2, the result didn't change. I couldn't figure
> it out.
>
> The case file is included in the attachment. Thank you for your help.
>
>
grid.m
Description: Binary data
Re: no solution to DC power flow
Thanks for your help :) On Thu, Mar 15, 2012 at 3:01 AM, Ray Zimmerman wrote: > It should be legitimate to set a generator bus as a PQ bus (i.e. turn off > any voltage control). This already works as expected I believe. > > The bug has to do with the way the voltages are initialized for the AC power > flow run. For a generator bus that is set as a PQ bus, it should use the > voltage magnitude in bus(:, VM), but it is currently using the voltage from > gen(:, VG). For a solved case, the gen(:, VG) value does not contain the > solved voltage, so running a power flow with the solved case as the input > does not converge immediately as it should. In fact, in this case, it is > such a bad starting point that the power flow diverges. > > -- > Ray Zimmerman > Senior Research Associate > 419A Warren Hall, Cornell University, Ithaca, NY 14853 > phone: (607) 255-9645 > > > > > On Mar 14, 2012, at 2:40 PM, Kelly, Michael W. wrote: > > Is the reason you are considering a bug for MATPOWER is that the 283 PQ > buses is near the bus limit of the network resulting in little freedom for a > definitive answer, or is there another reason? > > Thanks, > > Mike > > > Michael Kelly, Instructor > Lab FH-449, Office FH-370A > http://sce.umkc.edu/power/suggestedtexts.aspx > University of Missouri – Kansas City > School of Computing & Engineering > Flarsheim Hall, 5110 Rockhill Road, > Kansas City, Missouri 64110-2499 > cell (913) 375-6802 / land-line (816) 235-1254 / fax (816) 235-1260 > > From: bounce-42586047-27808...@list.cornell.edu > [bounce-42586047-27808...@list.cornell.edu] on behalf of Ray Zimmerman > [r...@cornell.edu] > Sent: Wednesday, March 14, 2012 1:26 PM > To: MATPOWER discussion forum > Subject: Re: no solution to DC power flow > > You have about 283 generator buses that are marked as PQ buses, rather than > PV buses. This is what is producing the problem with the AC power flow not > converging immediately when run using the solution as an input. I think this > should probably be considered a bug in MATPOWER. > > The other thing is that you have 4 lines with zero reactance. That is where > the NaN's come from in the DC power flow solution. And yes, the DC power > flow is simply the solution of a linear set of equations, so no iteration is > necessary. > > find(mpc.branch(:, BR_X) == 0) > > > ans = > > 3776 > 3784 > 5471 > 5959 > > -- > Ray Zimmerman > Senior Research Associate > 419A Warren Hall, Cornell University, Ithaca, NY 14853 > phone: (607) 255-9645 > >
Re: MU_PMIN & QMIN
I think each MU here (for PMIN, PMAX, VMIN, etc.) is one component of the Lagrangian multiplier μ in equation (A.32) in Appendix A. It is called Kuhn-Tucker multiplier, also known as shadow price. Am I right, Dr.Zimmerman? On Fri, Mar 30, 2012 at 9:36 PM, Ray Zimmerman wrote: > 1. runmarket uses the offers and bids to determine the PMAX and PMIN from > generators and dispatchable loads respectively. So if you have a PMIN value > of -100 MW in the case file (for a dispatchable load) and you submit bid > quantities totaling 80 MW, it will set PMIN to -80 before calling the OPF to > solve for the market solution. > > 2, 3 and 4. I'm not sure why you think they are computed differently. All of > the shadow prices on constraints are computed the same way. All of them are > sensitivities of the objective to the constraint in question and all are > computed internally by the non-linear solver being used. As I mentioned in > my first response to you, in the case of the default MIPS solver, they are > included in the mu variable in equation (A.32) in Appendix A. The values are > computed in mips.m. > > -- > Ray Zimmerman > Senior Research Associate > 419A Warren Hall, Cornell University, Ithaca, NY 14853 > phone: (607) 255-9645 > > > > > On Mar 29, 2012, at 4:12 PM, Carol Francesca wrote: > > Thank you. > > My questions are introduced as follows: > > 1.The value of Pmin in the case file and in the results are different while > they have to be the same. Why they are different when I am doing runmarket? > 2. The value MU_Pmin for dispatachable load and generators are computed in > different way, i.e. for generators it is calculated as explained in the > manual while for the dispatchable loads I don't know how they are > calculated. I want to know this(when I am doing runmarket). > 3. How MU_Pmax is calculated? > 4. Also, for voltage how they are calculated (MU_Vmin&max when I am doing > runmarket) > > I am so sorry for asking many questions. > > Best Regards > > C.F. > > > > On Thu, Mar 29, 2012 at 21:28, Ray Zimmerman wrote: >> >> PMIN is a lower limit on the amount of generation PG in MW. This is an >> input value set in the case file. The value of MU_PMIN is the sensitivity of >> the objective to this constraint, a shadow price computed by the >> optimization. Similarly for PMAX and MU_PMAX. If you don't understand shadow >> prices you will need to get that from a course or book on optimization >> theory. >> >> When using the smart market code (runmarket.m) PMIN (for loads) and PMAX >> (for generators) are modified according to the bid and offered quantities >> before calling the OPF. >> >> Does that help? >> >> -- >> Ray Zimmerman >> Senior Research Associate >> 419A Warren Hall, Cornell University, Ithaca, NY 14853 >> phone: (607) 255-9645 >> >> >> >> >> On Mar 29, 2012, at 12:27 PM, Carol Francesca wrote: >> >> Thank you for your response. >> >> My problem is the first: I don't understand how PMIN is computed in the >> result(it is different from the Pmin set in the case file)? MU_PMAX? >> >> MU_PMin for dispatchable loads and generators are calculated in a >> different way. I cannot understand this also why? >> >> Could you please explain these? >> >> Best Regards >> >> Carol Francesca >> >> >> >> On Thu, Mar 29, 2012 at 17:10, Ray Zimmerman wrote: >>> >>> Are you saying you do not understand what a shadow price on a constraint >>> is? Or that you do not understand a specific optimization algorithm (such as >>> the interior point method used by MIPS) and how these multipliers are >>> computed? >>> >>> If it is the first, I will just say, it is the sensitivity of the >>> objective function to the constraint. In other words, in the case of >>> MU_PMIN, for example, a shadow price of $X/MW means that the objective >>> function would decrease by $X*Y if you were to relax the PMIN limit by Y MW >>> for some tiny value of Y. >>> >>> If it is the second, I suggest that you take a course or read a book on >>> non-linear optimization. The algorithmic details of how these shadow prices >>> are actually computed is different for each algorithm and beyond the scope >>> of what I can explain in an e-mail. >>> >>> -- >>> Ray Zimmerman >>> Senior Research Associate >>> 419A Warren Hall, Cornell University, Ithaca, NY 14853 >>> phone: (607) 255-9645 >>> >>> >>> >>> >>> On Mar 28, 2012, at 4:13 PM, Carol Francesca wrote: >>> >>> Dear Dr. Zimmerman, >>> >>> I read the manual but I didn't understand how Pmin mu for dispatchable >>> loads as well as Pmax for generators are calculated. I really confused. If >>> it is possible please explain, because It is not clear for me how it has >>> been computed. >>> >>> Best Regards >>> >>> Carol Francesca >>> >>> >>> >>> On Mon, Mar 26, 2012 at 15:16, Ray Zimmerman wrote: MU_PMIN and MU_QMIN are shadow prices on the minimum generation limits for real and reactive power. Constraint shadow prices, also called Kuhn-Tucker multipliers, are a standard output of most all
Re: Power flow results question
I don't know whether you set the bus where your cap bank is located a PQ bus or a PV bus. From the unchanged results I could guess that it's a PQ bus. Keep in mind that when you do a simple load flow, voltage limits and generator output limits are not considered. In your case, Pg and Qg of the dummy generator are set to to zero. This leads to the output of the generator being zero when you do the load flow (because it is a PQ bus so the values of Pg and Qg are used). So the results won't change. Set the bus to a PV one. Then in load flow the capacitor will take effect.Or simply do an OPF and all the limits will be considered. Notice that in this way of modeling the cap banks, the capacity is adjusted continuously. Sorry, not a native speaker :) Hope this helps. On Fri, Apr 20, 2012 at 1:33 PM, Sam Hazim wrote: > > > > > Hi everyone, > I am new to Matpower, i have some few questions about power flow . > > I have been given in my assignment some possible locations for capacitor > banks to be placed on the system. > > 1: I want to make sure, to include any cap bank on any bus, is it correct > be placed within generator data matrix and set Pg,Qg,Qmin =0, vg=1, Qgmax= > 300 (value given in my assignment). > 2: from my knowledge, we use cap banks order to minimize losses or support > voltage.i tried to connect them to the high voltage bus or to the main > transform, or other locations and then runpf. the answer doesn't change at > all ( Why is that). i have got min voltage at one bus is about 0.831 and it > should be between a recommend range 0.95 to 1.05. > > I have included the case file for two modified cases.and runpf , the results > are the same for both of them. > > Please, any suggestions will be very helpful for me to tackle this problem. > > Raad > > function > mpc = case18 > %%- Power Flow Data -%% > %% system MVA base > mpc.baseMVA = 500; > %% bus data > % bus_i type Pd Qd Gs Bs area Vm Va baseKV zone Vmax Vmin > mpc.bus = [ > 1 3 0 0 0 0 1 1 0 220 1 1.05 0.95; > 2 1 0 0 0 0 1 1 0 220 1 1.05 0.95; > 3 2 0 0 0 0 1 1 0 220 1 1.05 0.95; > 4 1 0 0 0 0 1 1 0 220 1 1.05 0.95; > 5 2 0 0 0 0 1 1 0 220 1 1.05 0.95; > 6 1 200 50 0 0 1 1 0 220 1 1.05 0.95; > 7 1 450 115 0 0 1 1 0 220 1 1.05 0.95; > 8 2 0 0 0 0 1 1 0 220 1 1.05 0.95; > 9 1 0 0 0 0 1 1 0 220 1 1.05 0.95; > 10 1 0 0 0 0 1 1 0 220 1 1.05 0.95; > 11 1 0 0 0 0 1 1 0 220 1 1.05 0.95; > 12 1 200 50 0 0 1 1 0 110 1 1.05 0.95; > 13 1 150 40 0 0 2 1 0 110 1 1.05 0.95; > 14 1 250 65 0 0 2 1 0 110 1 1.05 0.95; > 15 1 750 190 0 0 2 1 0 110 1 1.05 0.95; > 16 2 0 0 0 0 2 1 0 33 1 1.05 0.95; > 17 1 0 0 0 0 2 1 0 220 1 1.05 0.95; > 18 2 0 0 0 0 2 1 0 110 1 1.05 0.95; > ]; > %% generator data > % bus Pg Qg Qmax Qmin Vg mBase status Pmax Pmin Pc1 Pc2 Qc1min Qc1max Qc2min > Qc2max ramp_agc ramp_10 ramp_30 ramp_q apf > mpc.gen = [ > 1 500 0 750 -200 1.05 500 1 1250 0 0 0 0 0 0 0 0 0 0 0 0; > 3 450 0 50 -150 1.05 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0; > 5 550 0 200 -150 1.028 500 1 600 0 0 0 0 0 0 0 0 0 0 0 0; > 8 50 0 65 -200 0.95 500 1 120 0 0 0 0 0 0 0 0 0 0 0 0; > 16 400 0 300 -40 1.022 500 1 500 0 0 0 0 0 0 0 0 0 0 0 0; > 18 250 0 220 -100 0.99 500 1 350 0 0 0 0 0 0 0 0 0 0 0 0; > 9 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0; > 12 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0; > 13 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0; > 14 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0; > 15 0 0 300 0 1 500 1 0 0 0 0 0 0 0 0 0 0 0 0 0; > ]; > %% branch data > % fbus tbus r x b rateA rateB rateC ratio angle status > mpc.branch = [ > 1 3 0.0712 0.3595 0.0982 524 0 0 0 0 1; > 4 5 0.0978 0.5855 0.0773 455 0 0 0 0 1; > 4 6 0.023 0.1615 0.01 671 0 0 0 0 1; > 4 7 0.0201 0.1548 0.0395 766 0 0 0 0 1; > 4 2 0.0112 0.1136 0.0071 766 0 0 0 0 1; > 7 2 0.0112 0.1136 0.0071 766 0 0 0 0 1; > 7 9 0.01 0.0954 0.0058 915 0 0 0 0 1; > 1 6 0.042 0.2715 0.017 493 0 0 0 0 1; > 1 7 0.088 0.5675 0.0356 323 0 0 0 0 1; > 1 17 0.0444 0.2104 0.0247 323 0 0 0 0 1; > 7 17 0.0444 0.2104 0.0247 323 0 0 0 0 1; > 7 18 0. 0.08 0.00 2000 0 0 1 0 1; > 7 8 0.002 0.0175 0.0011 915 0 0 0 0 1; > 7 15 0. 0.05 0.00 2000 0 0 1 0 1; > 8 9 0.009 0.0775 0.0047 915 0 0 0 0 1; > 9 10 0.0095 0.078 0.005 827 0 0 0 0 1; > 9 11 0.079 0.4815 0.0191 408 0 0 0 0 1; > 9 14 0.00 0.15 0.00 2000 0 0 1 0 1; > 10 11 0.044 0.3585 0.0233 456 0 0 0 0 1; > 10 12 0. 0.15 0.00 2000 0 0 1 0 1; > 11 13 0.0 0.30 0.00 2000 0 0 1 0 1; > 4 16 0.00 0.131 0.00 2000 0 0 1 0 1; > 3 5 0.036 0.2396 0.0667 870 0 0 0 0 1; > ]; > %%- OPF Data -%% > %% generator cost data > % 1 startup shutdown n x1 y1 ... xn yn > % 2 startup shutdown n c(n-1) ... c0 > mpc.gencost = [ > 2 0 0 3 0.039 20 0; > 2 0 0 3 0.029 20 0; > 2 0 0 3 0.031 20 0; > 2 0 0 3 0.12 20 0; > 2 0 0 3 0.25 20 0; > 2 0 0 3 0.1 20 0; > 2 0.01 0 3 0.01 40 0; > 2 0.01 0 3 0.01 40 0; > 2 0.01 0 3 0.01 40 0; > 2 0.01 0 3 0.01 40 0; > 2 0.01 0 3 0.01 40 0; > ]; > > This is the modifed case > > function > mpc = case18 > %%- Power Flow Data -%% > %% system MVA
