>From Carlos Murillo (who is having issues sending e-mail) …. Tatiana:
Actually, let me explain a bit what is going on. Ramps from base cases at time t to base cases at time t+1 determine the amount of required ramping reserve needed at time t. But, the ramping reserve for the transition from t=0 to t=1 would be data, not a variable to decide, because you have what reserve you have at that time. Accordingly, MOST does not actually put constraints on the ramping transitions from t=0 to t=1; if this is really needed, then you need to modify the Pmax and Pmin of the generators at t=1 based on the ramping limit and the value of the InitialPg parameter. This might need some revising of the manual. carlos. > On Oct 14, 2016, at 9:35 AM, Tatiana Carolina Cantillo Garcia > <[email protected]> wrote: > > Hi Ray, > Thank you very much for quick reply. > I'm working on the unit commitment example presented in the MOST manual > (Example 6). This is the code i'm using: > > casefile = 'ex_case3b'; > mpc = loadcase(casefile); > xgd = loadxgendata('ex_xgd_uc', mpc); > [iwind, mpc, xgd] = addwind('ex_wind_uc', mpc, xgd); > profiles = getprofiles('ex_wind_profile_d', iwind); > profiles = getprofiles('ex_load_profile', profiles); > nt = size(profiles(1).values, 1); % number of periods > mpc_full = mpc; > xgd_full = xgd; > xgd.PositiveLoadFollowReserveQuantity(1) = 10; > xgd.NegativeLoadFollowReserveQuantity(1) = 10; > mpc.gen(1,RAMP_30)=10; > mpc.gen(1,RAMP_30)=10; > mpc.gen(1,RAMP_10)=10; > mpc.gen(1,RAMP_10)=10; > xgd.InitialPg(1)=100; > mdi = loadmd(mpc, nt, xgd, [], [], profiles); > mdo = most(mdi, mpopt); > if verbose > ms = most_summary(mdo); > end > I would expect the generation dispatch of the first unit at the first period > to be restricted to 110MW. However, the results show that the generation > dispatch of the first unit at the first period is 200MW. > > ========== PG ========== > Gen t = 1 t = 2 t = 3 t = 4 t = 5 t = 6 t = 7 t = 8 > t = 9 t =10 t =11 t =12 > ---- ------- ------- ------- ------- ------- ------- ------- ------- > ------- ------- ------- ------- > 1 200.00 190.00 180.00 190.00 184.00 174.00 164.00 154.00 > 144.00 154.00 144.00 154.00 > 2 - - - - - 96.00 126.00 65.00 > - - 65.00 116.00 > 3 160.00 225.00 300.00 253.00 216.00 110.00 60.00 60.00 > 60.00 61.00 60.00 60.00 > 4 -440.00 -480.00 -540.00 -525.00 -500.00 -450.00 -400.00 -350.00 > -300.00 -325.00 -375.00 -425.00 > 5 80.00 65.00 60.00 82.00 100.00 70.00 50.00 71.00 > 96.00 110.00 106.00 95.00 > > I don´t really understand the problem. What can I do? > > Thank you very much, > Tatiana > > > > > 2016-10-14 7:47 GMT-05:00 Ray Zimmerman <[email protected] > <mailto:[email protected]>>: > Hi Tatiana, > > Your understanding seems to be correct, so it’s difficult for me to know > what’s going on. Could you send me (off list) the input files and a minimal > script needed to reproduce the problem so I can look into it? > > Thanks, > > Ray > > >> On Oct 13, 2016, at 10:39 AM, Tatiana Carolina Cantillo Garcia >> <[email protected] <mailto:[email protected]>> wrote: >> >> Dear all, >> >> I have a question about setting ramp constrains in the multiperiod problem >> in MOST. >> I have noticed that the ramp constrains (which are defined in the RAMP_30 , >> PositiveLoadFollowReserveQuantity and NegativeActiveReserveQuantity columns >> of the gen and the xgd matrix) are violated in the period t=0 to t=1. >> For example, I have fixed the ramping limits of the first unit of my >> optimization problem to 10MW ( mpc.gen(1,RAMP_30)=10, >> xgd.PositiveLoadFollowReserveQuantity(1)=10), and the active power dispatch >> at time t=0 (previous to optimization) is set to 100MW ( >> xgd.InitialPg(1)=100). Thus, I would expect, the generation dispatch of the >> first unit at the first period to be restricted to 110MW. However when I run >> the multiperiod problem, the results show that the generation dispatch of >> the first unit at the first period is 200MW. >> >> How can I correct this? >> >> Thank you very much, >> Tatiana Cantillo >> >> >> >> Este correo no representa opinión o consentimiento oficial de la Universidad >> del Norte, por lo que esta no adquiere ninguna responsabilidad por su >> contenido, salvo en el caso de funcionarios en ejercicio de atribuciones >> reglamentarias. Puede provenir de una cuenta ofrecida a funcionarios o >> estudiantes, como parte del ejercicio educativo, evento en el cual tanto el >> mensaje como sus anexos son estrictamente confidenciales. Ha sido analizado >> con software antivirus; no obstante, no se garantiza que sea seguro o no >> contenga errores o virus, por lo que la Universidad del Norte no se hace >> responsable de su transmisión. > > > > Este correo no representa opinión o consentimiento oficial de la Universidad > del Norte, por lo que esta no adquiere ninguna responsabilidad por su > contenido, salvo en el caso de funcionarios en ejercicio de atribuciones > reglamentarias. Puede provenir de una cuenta ofrecida a funcionarios o > estudiantes, como parte del ejercicio educativo, evento en el cual tanto el > mensaje como sus anexos son estrictamente confidenciales. Ha sido analizado > con software antivirus; no obstante, no se garantiza que sea seguro o no > contenga errores o virus, por lo que la Universidad del Norte no se hace > responsable de su transmisión.
