You’ll have to write your own code to implement the second option I mentioned before, namely …
The other option is simply to run the single-period OPF (using runopf) sequentially for each hour in a loop and use the ramp rate to limit the feasible dispatch range in the input to runopf. That is, you would set the PMIN and PMAX for each generator in hour t to the more restrictive of (1) the physical capacity limits of the generator, (2) the maximum down/up ramp from the hour t–1 dispatch. If you are using a 1 hour time step, you would probably want to use two times RAMP_30 for the maximum dispatch change. So to restrict the input for the OPF for hour t, you would do something like the following, where results contains the OPF result from hour t–1, and mpc contains the input case for hour t … ramp_Pmax = results.gen(:, PG) + 2 * results.gen(:, RAMP_30); ramp_Pmin = results.gen(:, PG) - 2 * results.gen(:, RAMP_30); mpc.gen(:, PMIN) = max(mpc.gen(:, PMIN), ramp_Pmin); mpc.gen(:, PMAX) = min(mpc.gen(:, PMAX), ramp_Pmax); Ray On Mar 5, 2020, at 9:59 AM, Yang <[email protected]<mailto:[email protected]>> wrote: Thanks, Ray. So, how can I use ramp rate in this? What work or code can I do? Yang. ------------------ Original ------------------ From: Ray Daniel Zimmerman <[email protected]<mailto:[email protected]>> Date: Thu,Mar 5,2020 0:30 AM To: MATPOWER-L <[email protected]<mailto:[email protected]>> Subject: Re: how to modify parameter to redcuce branch power 1. The mu values are the shadow prices on the constraints. So they represent the marginal value of relaxing that constraint by 1 unit. That is, if you relax the bound on the constraint by a small value epsilon, you would expect the objective function to decrease by mu * epsilon. So in your case, if you were to change Vmax at bus 1 to 1.07, you can expect the objective function to decrease by about $2.71. Because of the scale of the units of voltage a number like 270 is reasonable. It’s not a $/MW number like the shadow price on a power constraint. 2. The value of RAMP_AGC is actually not used internally by runopf() at all, so this is expected. Unless you are using RAMP_AGC and the dispatch from a previous period to restrict PMIN and PMAX in your input to runopf(), it won’t affect anything. 3. The nodal prices for active power at each bus are displayed in the bus table as Lambda P, and are available in the results struct as results(:, LAM_P). If you turn on the generator section in the output (set out.gen option to 1), it will also display the nodal price of the corresponding bus next to each generator. Best regards, Ray On Mar 4, 2020, at 10:02 AM, Yang <[email protected]<mailto:[email protected]>> wrote: Dear Ray, Thanks for your patience! I tried to do in the first way in the last mail. 1. These are part of results. I have some questions about Vmax mu,Qmax mu, etc. I just know these are some parameters of KKT, and I doesn't understand its meaning very well, like bus #1, its Vmax mu is 270.571(maybe too large?), so I wonder whether the result is proper. ================================================================================ | Voltage Constraints | ================================================================================ Bus # Vmin mu Vmin |V| Vmax Vmax mu ----- -------- ----- ----- ----- -------- 1 - 0.940 1.060 1.060 270.571 11 - 0.940 1.060 1.060 53.835 13 - 0.940 1.060 1.060 68.797 ================================================================================ | Generation Constraints | ================================================================================ Gen Bus Reactive Power Limits # # Qmin mu Qmin Qg Qmax Qmax mu ---- ----- ------- -------- -------- -------- ------- 1 1 0.059 0.00 0.00 10.00 - 4 8 - -10.00 40.00 40.00 0.054 2. I change the ramp_agc, but results are same, I don't find the reason. 3. May I know the price of each generator in the final result and where can I find it? Thank you very much for your patience in answering my questions, even if it is very simple. Under your careful guidance, I read the manual and become more and more familiar with matpower. Best wishes. Yang. At 2020-03-04 05:33:50, "Ray Daniel Zimmerman" <[email protected]<mailto:[email protected]>> wrote: See my responses to each question below ... On Mar 3, 2020, at 10:07 AM, Yang <[email protected]<mailto:[email protected]>> wrote: Deae Ray, Thanks for your reply, and I have dour questions as folllows. 1. If I have daily load data, like total load = [270.33 257.07 247.20 243.93 247.20 253.47 ... ](24 data), I wrote a loop to run, and use apply_changes to input these data, and change ramp rate to implement it. Is this method right? In this way, it likes I change data by hand and then I get results. From what you said, my understanding is that it takes ramp rate in account, but not very perfect. That sounds correct to me. 2. If I do as what I think in 1., the sum Pd change, and how do every bus load change? I want to use case30.m, do every bus change in proportion to the change of total load? It depends how you define the changes you apply with apply_changes(). If you are using a single value (system-wide load) and applying it with the CT_ROW column equal to 0 (apply to all rows), then, yes, it will scale the loads proportionally to make the total equal the value you specify. 3. If I want to achieve 1. by using MOST, the case is supposed to be simplified into DC model. Yes, MOST uses a linearized DC model approximation of the network. 4. If I want to reduce 10% active power of the branch 15-23 in case30.m, do I change the rate A of bus 15 or bus 23, or both? using chgtab = [1 0.002 CT_TBRCH 30 RATE_A CT_REL 0.9;]; You have to find the row index in the branch matrix of the line from bus 15 to bus 23, and use that as the row index. Hope this helps, Ray I don't know whether it is right. Warm regards. Yang. At 2020-03-03 00:31:27, "Ray Daniel Zimmerman" <[email protected]<mailto:[email protected]>> wrote: There are two main options ... If a linearized DC model of the network is adequate for your purposes, then MOST is probably the way to go. It can solve a full multi period OPF problem taking into account ramp limits. This allows restrictions in one period to affect the dispatch in previous periods, finding the dispatch trajectories that are optimal for the entire planning horizon. The other option is simply to run the single-period OPF (using runopf) sequentially for each hour in a loop and use the ramp rate to limit the feasible dispatch range in the input to runopf. That is, you would set the PMIN and PMAX for each generator in hour t to the more restrictive of (1) the physical capacity limits of the generator, (2) the maximum down/up ramp from the hour t–1 dispatch. The latter is simpler and allows you to use an AC network model, but dispatches in a given hour are not affected at all by future hours, only past hours, so the overall trajectory may not be optimal. For example, you won’t start ramping up a cheaper slow ramping unit ahead of time to be available for a peak hour, since that would require “look-ahead”. Hope this helps, Ray On Mar 1, 2020, at 12:32 PM, yang_hong_yue <[email protected]<mailto:[email protected]>> wrote: Dear Ray, I want to run opf with 24h daily load, how can I add the ramp rate constraint in code? Can I make it in add some codes or in MOST? Thanks a lot. Yang. ------------------ Original ------------------ From: Ray Daniel Zimmerman <[email protected]<mailto:[email protected]>> Date: Sat,Feb 29,2020 6:36 AM To: MATPOWER-L <[email protected]<mailto:[email protected]>> Subject: Re: how to modify parameter to redcuce branch power The RATE_A column of the branch matrix is used by the OPF to constrain the branch flow. Ray On Feb 28, 2020, at 7:35 AM, Yang <[email protected]<mailto:[email protected]>> wrote: Dear everyone, I want to reduce the power of branch, which parameter value should be changed in OPF? For example,if I want to reduce 50% power of branch 15-23 in case30.m, how can I make it? Thanks a lot. Best wishes. Yang
