# Re: Setting ramp constrains in unit commitment problem in MOST.

```>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
> <tcanti...@uninorte.edu.co> 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';
> [iwind, mpc, xgd] = addwind('ex_wind_uc', mpc, xgd);
> profiles = getprofiles('ex_wind_profile_d', iwind);
> nt = size(profiles(1).values, 1);       % number of periods
> mpc_full = mpc;
> xgd_full = xgd;
> 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 <r...@cornell.edu
> <mailto:r...@cornell.edu>>:
> 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
>> <tcanti...@uninorte.edu.co <mailto:tcanti...@uninorte.edu.co>> 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 ,
>> 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.

```