makePTDF - what is the point of using slack argument?
Hi, I was looking at the makePTDF function and was a bit confused with the option for having distributed slack. Instead of feeding the distributed slack weights to makePTDF(mpc,slack) you can just add the slack to the delta power injections. For example the following options give exactly the same result (4-buses): dP = [1 0 0 0 ], with slack = [0 1/2 1/2 0 ] dP = [1 -1/2 -1/2 0 ], default slack Is always the case? In that case it seems you can just forget about using the slack argument. Regards, Elis Nycander Example code: % PTDF_test mpc = case24_ieee_rts; nb = size(mpc.bus,1); %% using distributed slack w = zeros(nb,1); w([13 14 22]) = 1/3; % slack at bus 13,14,22 H2 = makePTDF(mpc,w); % distributed slack dP2 = diag( ones(nb,1) ); % unit injection at each bus dL2 = H2*dP2; %% using default slack with modified injections H1 = makePTDF(mpc); % default slack configuration dP1 = dP2; for i=1:size(dP1,2) dP1(:,i) = dP1(:,i) - w; % add compensation from slack end dL1 = H1*dP1; diff = max(max(abs(dL1 - dL2))) % <- answers are the same
Re: negative line parameters from psse_convert_xfmr
Maybe this can explain why a number of branches in case145 have negative series resistance and impedance. I was wondering why this was the case. Regards, Elis Den mån 3 sep. 2018 kl 08:29 skrev Jose Luis Marín : > > I remember I did check extensively the conversion of two-winding > transformers a few years back; however, I did not check 3-winding ones. > > You can check those formulas in this article by Siemens: > > "Modeling of Three-Winding Voltage Regulating Transformers for Positive > Sequence Load Flow Analysis in PSS/E" > > https://w3.usa.siemens.com/datapool/us/SmartGrid/docs/pti/2010July/PDFS/Modeling%20of%20Three%20Winding%20Voltage%20Regulating%20Transformers.pdf > > -- > Jose L. Marin > Grupo AIA > > > > 2018-08-31 0:12 GMT+02:00 Ray Zimmerman : > >> This code was contributed by Yujia Zhu when he was at ASU working with >> Dan Tylavsky. I’m afraid I’m not familiar with the details of that code, >> but I’m pretty sure it was double-checked extensively against PSS/E’s >> internal models. >> >> Ray >> >> >> On Aug 6, 2018, at 4:50 AM, Aebi Stefanie >> wrote: >> >> Dear all >> >> >> I am trying to convert a PSSE .raw network case to mpc format. >> >> >> I just discovered that I obtain negative branch parameters for some of >> the 3-winding transformers in my System, i.e. x < 0, r < 0. I tried to >> track the phenomenon and found the following section in psse_convert_xfmr.m: >> >> >> R1 = (R12+R31-R23) ./ 2; >> R2 = (R12+R23-R31) ./ 2; >> R3 = (R31+R23-R12) ./ 2; >> X1 = (X12+X31-X23) ./ 2; >> X2 = (X12+X23-X31) ./ 2; >> X3 = (X31+X23-X12) ./ 2; >> >> >> I've got a number of branches where the negative term (e.g. R23 in >> calculation of R1) is the biggest one, such that the resulting R or X is >> negative. >> >> >> Where does this definition come from? >> And is there a way I can avoid getting negative line parameters? >> >> >> Thanks for your help. >> >> >> Kind regards, >> Stefanie Aebi >> >> >> >
Branch model - switch FROM and TO bus?
Hi, In the matpower branch model (Fig 3.1) the impedance is on the TO-bus side. However, since the impedance is in pu, for an ideal transformer we might as well move the pu impedance to the FROM-bus right? So in this case we can exchange the TO-bus and FROM-bus for any branch without effecting the results of a load flow. Q1. So when does the the ordering of the FROM and TO bus actually matter? Is there any case when we cannot swich the TO and FROM bus of a branch and still get the same result from a load flow or opf? Q2. From Figure 3.1 it looks as if the FROM bus is the high voltage bus (assuming N > 1). Is this always the case or can we have N < 1 just as well? Regards, Elis
Re: Tap ratios set to 0, run OPF with tap changers
Hey, thanks for your answers. Indeed the solution is the same if the tap ratios are set to 0 or 1 (as long as the SHIFTS are all 0), it was just an error on my part. Ah, no callback for OPF? I just assumed that there was something similar to the callback functions in the CPF. Thanks for the links. Regards, Elis 2017-09-25 18:34 GMT+02:00 Abhyankar, Shrirang G. : > > > Dear Matpower users, > > I have some questions about tap ratios in Matpwer. > > What does it mean if the tap ratios TAP are set to 0? > > Tap ratio=0 is used to indicate that the branch is a non-transformer > branch, while 1 indicates a transformer branch. Even if you set the tap > ratio = 0 for a transformer, MATPOWER internally uses a unity tap ratio > meaning a 1:1 voltage transformation. > > I have previously run some power flows without caring about the tap > ratios (TAP = 0). Now I set them to 1, and got quite different results. > > I don’t think this should happen. With 0 or 1, the power flow results > should be same. > > I can't see that the admittance matrix in Figure 3.1 in the manual is well > defined for zero tap ratio, so I thought setting them to 0 was like > deactivating them. > > Also, if I want to run an OPF with active tap changers, would it be best > to include the tap ratios directly in the optimization constraints or to > change the tap ratios in a callback function? Or maybe I can run several > OPFs and change the tap ratios manually between each? > > Incorporating tap changers in OPF is a non-trivial task. Moreover, I don’t > think there is a callback function in PF or OPF. > > Here are some relevant discussions from the mailing list. > > https://www.mail-archive.com/matpower-l@cornell.edu/msg04162.html > > https://www.mail-archive.com/matpower-l@cornell.edu/msg03339.html > > Note that there is a pending pull request for this feature. You can try > that out if you like. > > Shri > > > Regards, > Elis Nycander >
Tap ratios set to 0, run OPF with tap changers
Dear Matpower users, I have some questions about tap ratios in Matpwer. What does it mean if the tap ratios TAP are set to 0? I have previously run some power flows without caring about the tap ratios (TAP = 0). Now I set them to 1, and got quite different results. I can't see that the admittance matrix in Figure 3.1 in the manual is well defined for zero tap ratio, so I thought setting them to 0 was like deactivating them. Also, if I want to run an OPF with active tap changers, would it be best to include the tap ratios directly in the optimization constraints or to change the tap ratios in a callback function? Or maybe I can run several OPFs and change the tap ratios manually between each? Regards, Elis Nycander
Re: CPF bug when cpf_corrector failes on first iteration
Hi Ray, Sorry for late reply. I have created a new issue in the github tracker. Regards, Elis 2017-08-10 15:43 GMT+02:00 Ray Zimmerman : > Thanks for catching this. Would you mind creating a bug report with these > details the GitHub issue tracker > <https://github.com/MATPOWER/matpower/issues>? > > Thanks, > > Ray > > > On Aug 8, 2017, at 9:06 AM, Elis Nycander wrote: > > Hi, > > I have found a small bug in the CPF function. Suppose the base case power > flow converges but the very first corrector step fails. Then the following > happens > > 1. cpf loop sets *cont_steps = 0 *and terminates with break > 2. callback function is called with *k=0 *and thus executes > initialization instead of final callback loop > 3. *cpf_results *is now missing the field *V *(and all other fields which > are supposed to be set in final callback loop) > 4. missing *cpf_results.V *causes error on line 610 in runcpf: > n = size(cpf_results.V, 2); > > So the reason for this error is that the first parameter taken by the > callback functions has two different functions. It is both > 1. An indicator what stage the cpf is in, i.e. initialization stage, > continuation stage, or final stage > 2. A counter for the number of iterations which has been run > So the possibility of being in the final stage (because the corrector did > not converge) in the very first iteration creates problems. > > I have attached an example where this happens. It is a modified version of > case4gs. > > Regards, > Elis Nycander > > > >
CPF bug when cpf_corrector failes on first iteration
Hi, I have found a small bug in the CPF function. Suppose the base case power flow converges but the very first corrector step fails. Then the following happens 1. cpf loop sets *cont_steps = 0 *and terminates with break 2. callback function is called with *k=0 *and thus executes initialization instead of final callback loop 3. *cpf_results *is now missing the field *V *(and all other fields which are supposed to be set in final callback loop) 4. missing *cpf_results.V *causes error on line 610 in runcpf: n = size(cpf_results.V, 2); So the reason for this error is that the first parameter taken by the callback functions has two different functions. It is both 1. An indicator what stage the cpf is in, i.e. initialization stage, continuation stage, or final stage 2. A counter for the number of iterations which has been run So the possibility of being in the final stage (because the corrector did not converge) in the very first iteration creates problems. I have attached an example where this happens. It is a modified version of case4gs. Regards, Elis Nycander example.mat Description: Binary data mwe.m Description: application/vnd.wolfram.mathematica.package
Re: CPF - converted generator buses have 0 QG
Thanks Ray, I don't think its a duplicate of that bug. I have submitted a new issue about this. Regards, Elis 2017-05-30 22:28 GMT+02:00 Ray Zimmerman : > Any chance this is a duplicate of issue #12 > <https://github.com/MATPOWER/matpower/issues/12>? If so, it should be > fixed in the current version on GitHub. If not, could you please submit a new > issue <https://github.com/MATPOWER/matpower/issues> with a minimum > working example (MWE) that I can use to reproduce the issue and look into > it? > > Thanks, > > Ray > > > > On May 29, 2017, at 11:06 AM, Elis Nycander > wrote: > > Hi, > > I'm running a cpf. In the base case there are some generators which are at > their maximum generation limit, so these are converted to PQ buses in the > base case pf. Then, on row 272 and 284 in runcpf, the QG for these buses > becomes 0 since they are not updated like the other generator buses. So > instead of the generator being a PQ bus with Pmax, Qmax, I get a PQ bus > with Pmax, 0. Is it supposed to be like this or is it a bug? > > I tried changing the code but couldn't see any big difference in my case. > > Help is kindly appreciated, > Elis > > >
CPF - converted generator buses have 0 QG
Hi, I'm running a cpf. In the base case there are some generators which are at their maximum generation limit, so these are converted to PQ buses in the base case pf. Then, on row 272 and 284 in runcpf, the QG for these buses becomes 0 since they are not updated like the other generator buses. So instead of the generator being a PQ bus with Pmax, Qmax, I get a PQ bus with Pmax, 0. Is it supposed to be like this or is it a bug? I tried changing the code but couldn't see any big difference in my case. Help is kindly appreciated, Elis
Re: Power flow VM VA, CPF end point
I see, that's interesting. Thanks!
2017-05-22 10:00 GMT+02:00 Jose Luis Marín :
>
> 1. Yes, VM VA are used both for input and output. Note one subtle point,
> though: in runpf.m (Lines 177--183) the initial seed for the iteration is
> first set to the values [VM VA] provided as input, but for
> voltage-controlled buses (with active generators), the value of VM is
> replaced by the setpoint VG of their respective bus generator(s) (the value
> of VA is preserved). This makes sense because it guarantees that the seed
> will be closer to the solution.
>
> 2. What you see here is to be expected. Basically, what happens is that
> the basins of attraction of low-voltage volutions are usually smaller than
> those of the operating solution. Also, note that there are *many* (for N
> buses, somewhat of the order of 2^N) low voltage solutions, so chances are
> that the iteration will converge to a solution that's different from the
> one you followed by homotopy (CPF). Even homotopy methods can encounter
> this same problem if their step-size is not small enough.
>
>
> Here's some refs on the fractal nature of the problem:
>
> @INPROCEEDINGS{KlumpOverbye00b,
> author={Klump, R.P. and Overbye, T.J.},
> booktitle={Power Engineering Society Summer Meeting},
> title={A new method for finding low-voltage power flow solutions},
> publisher={IEEE},
> year={2000},
> volume={1},
> pages={593--597},
> doi={10.1109/PESS.2000.867653},
> ISSN={}
> }
>
> @INPROCEEDINGS{ThorpNaqavi89,
> author={Thorp, J.S. and Naqavi, S.A.},
> booktitle={Proceedings of the 28th IEEE Conference on Decision and
> Control},
> title={Load flow fractals},
> year={1989},
> volume={2},
> pages={1822--1827},
> doi={10.1109/CDC.1989.70472}
> }
>
> @INPROCEEDINGS{ThorpNaqaviChiang90,
> author={Thorp, J.S. and Naqavi, S.A. and Chiang, H.-D.},
> booktitle={Decision and Control, 1990., Proceedings of the 29th IEEE
> Conference on},
> title={More load flow fractals},
> year={1990},
> month={dec},
> volume={6},
> pages={3028--3030},
> doi={10.1109/CDC.1990.203339}
> }
>
> @ARTICLE{ThorpNaqavi97,
> author={Thorp, J.S. and Naqavi, S.A.},
> journal=IEEE_M_CAP,
> title={Load-flow fractals draw clues to erratic behaviour},
> year={1997},
> month={jan},
> volume={10},
> number={1},
> pages={59--62},
> doi={10.1109/67.560872},
> ISSN={0895-0156}
> }
>
> @INPROCEEDINGS{Mori00,
> author={Mori, H.},
> booktitle={IEEE International Symposium on Circuits and Systems (ISCAS)},
> title={Chaotic behavior of the Newton-Raphson method with the optimal
> multiplier for ill-conditioned power systems},
> year={2000},
> volume={4},
> pages={237--240},
> doi={10.1109/ISCAS.2000.858732}
> }
>
>
> --
> Jose L. Marin
> Grupo AIA
>
>
>
>
> 2017-05-19 11:30 GMT+02:00 Elis Nycander :
>
>> Hi all matpower users!
>>
>> I have two questions:
>>
>> 1. In the bus matrix, the columns VM and VA are used both for the initial
>> guess when solving the power flow, and to store the resulting voltages?
>>
>> 2. When solving a cpf, I get lam_max which corresponds to the nose point,
>> i.e. maximum load/generation increase before "voltage collapse" happens. I
>> can also find the power flow at the nose point just by running an ordinary
>> power flow with flat start and conditions corresponding to the maximum
>> load. However, I have tried to do the same thing for the lower part of the
>> PV curve but failed to reproduce the solutions from the cpf. Basically I
>> thought I could get the lower part of the PV curve by just solving a power
>> flow using initial conditions which are close to the "unstable"/lower
>> solutions from the cpf (instead of a flat start), but I get different
>> solutions.
>>
>> Thanks,
>> Elis
>>
>
>
Power flow VM VA, CPF end point
Hi all matpower users! I have two questions: 1. In the bus matrix, the columns VM and VA are used both for the initial guess when solving the power flow, and to store the resulting voltages? 2. When solving a cpf, I get lam_max which corresponds to the nose point, i.e. maximum load/generation increase before "voltage collapse" happens. I can also find the power flow at the nose point just by running an ordinary power flow with flat start and conditions corresponding to the maximum load. However, I have tried to do the same thing for the lower part of the PV curve but failed to reproduce the solutions from the cpf. Basically I thought I could get the lower part of the PV curve by just solving a power flow using initial conditions which are close to the "unstable"/lower solutions from the cpf (instead of a flat start), but I get different solutions. Thanks, Elis
