I’m afraid I can’t guess without seeing the details of what you are doing. But, 
have you confirmed that the load profile is not being applied? Is the 
generation schedule in the result completely flat?

If so, can you share the load profile file you are using? It should look 
something like ex_load_profile.m.

    Ray



> On Sep 26, 2018, at 2:48 PM, Michal Polecki <[email protected]> 
> wrote:
> 
> Dear Profesor,
> 
> first of all thank you for your time. To tell the story short: I want to 
> perform ecomonic wind power curtailment. 
> 
> Yes, I meant length of the planning hotizon (usually called nt).
> I model wind as deterministic.
> Yes, the wind is included in the commitment (this is the purpose of the whole 
> analysis. As I wrote, my goal is to observe the economic curatilment of wind 
> farms)
> I started from zero costs of start-ups and shutdowns. What is unexpected 
> about the results is the fact that program gives me fixed UC. You have 
> already written in the other e-mail that: 
> 
> "My question was whether you checked the MOST results for the cases that run 
> but do not include any startup or shutdown of units to confirm that the total 
> generation is tracking the load profile you are attempting to specify. If 
> there is an error somewhere in the inputs that prevents the load profile 
> being applied as expected, it would result in a fixed commitment schedule 
> like this"
> 
> I don't know what could be "an error somewhere in the inputs that prevents 
> the load profile being applied as expected". I think you have precisely 
> described my problem, but I dont know where the error could appear. Could you 
> suggest me anything?
> 
> Best Regards,
> Michał Połecki
> 
> On 09/17/18 19:04, Ray Zimmerman <[email protected]> wrote:
>> 
>> I don’t think we have enough details of the case you are running and what 
>> you find unexpected about the results and why.
>> 
>> 
>> What do you mean by “longest possible number of terms”? Do you mean the 
>> maximum length of the planning horizon?
>> Are you modeling the wind as stochastic or deterministic?
>> Are you including wind in the commitment? I would recommend setting them as 
>> must-run with PMIN = 0.
>> 
>>     Ray
>> 
>>> On Sep 13, 2018, at 10:09 AM, Michal Polecki <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Dear All,
>>> 
>>> I've wrote a script which is checking longest possible number of terms in 
>>> most. In my case it was 152 terms (for 118 bus case with 13 wind farms). As 
>>> I previously written it is not clear to me why the Gurobi is chosing the 
>>> solution in which there is no Startup and shutdown. In case Pmin of 
>>> convetional generation greater than Pload it is curtailing wind generation 
>>> (which gencost is zero). I've attached plut_uc of the result file.
>>> 
>>> This is options I have.
>>> 
>>> mpopt = mpoption('verbose', verbose);
>>> mpopt = mpoption(mpopt, 'out.gen', 1);
>>> mpopt = mpoption(mpopt, 'model', 'AC');
>>> mpopt = mpoption(mpopt, 'most.skip_prices',1);
>>> mpopt = mpoption(mpopt, 'most.solver', 'gurobi');
>>> mpopt = mpoption(mpopt, 'most.uc.run', '1');
>>> mpopt = mpoption(mpopt, 'gurobi.method', -1);       %% automatic
>>> % mpopt = mpoption(mpopt, 'gurobi.method', 0);        %% primal simplex
>>> % mpopt = mpoption(mpopt, 'gurobi.method', 1);        %% dual simplex
>>> % mpopt = mpoption(mpopt, 'gurobi.method', 2);        %% barrier
>>> mpopt = mpoption(mpopt, 'gurobi.threads', 2);
>>> mpopt = mpoption(mpopt, 'gurobi.opts.MIPGap', 0);
>>> mpopt = mpoption(mpopt, 'gurobi.opts.MIPGapAbs', 0);
>>> 
>>> Best Regards,
>>> Michał Połecki
>>> 
>>> On 09/10/18 21:15, Michal Polecki <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> Thank you for your answer.
>>>> 
>>>> 1) I have already checked if the load can be covered by generation and if 
>>>> the ramps of generators are  suffcient. I'll do it one more time, thank 
>>>> you.
>>>> 
>>>> 2)  Gurobi gives exitflag -4.
>>>> 
>>>> Best Regards,
>>>> Michał Połecki
>>>> 
>>>> On 09/10/18 16:20, Ray Zimmerman <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> Did you check that the load profile is working correctly? Is the total 
>>>>> generation dispatch following the load profile you expected?
>>>>> 
>>>>> Also, what do you mean “it is impossible for MATPOWER to calculate” for 
>>>>> the 24 hour horizons? Does Gurobi run forever, find that the problem is 
>>>>> infeasible, or what?
>>>>> 
>>>>>    Ray
>>>>> 
>>>>> 
>>>>> 
>>>>> > On Sep 10, 2018, at 8:24 AM, Michal Polecki 
>>>>> > <[email protected] <mailto:[email protected]>> 
>>>>> > wrote:
>>>>> > 
>>>>> > Dear Creators and Users of Matpower,
>>>>> > 
>>>>> > I have a problem with Unit Commiment problem. I've studied all examples 
>>>>> > attached to Matpower and also I've created some more cases before going 
>>>>> > to my large problem. It seemed to give me correct results. I'm using 
>>>>> > Gurobi.
>>>>> > Now I'm trying to run 118 bus case with 13 additional wind farms. What 
>>>>> > I have observed is, that MATPOWER is sticking to the first plan of work 
>>>>> > (no startups or shutdowns though cost of it is 0). What is more  is 
>>>>> > some cases it is impossible for MATPOWER to calculate long period e.i 
>>>>> > nt = 24. I have written simple script to cut this long period into 4 
>>>>> > 6-hour periods. Then Matpower was able to calculate each of them. 
>>>>> > Plot_UC of each 6-hour period is attached.
>>>>> > 
>>>>> > Do you have an idea what could be problem? 
>>>>> > 
>>>>> > 
>>>>> > nt = 6;
>>>>> > mpc = loadcase('MMcase118v5');
>>>>> > Pg = mpc.gen(:,PG);
>>>>> > 
>>>>> > for i = 1:4
>>>>> >     result = MM_118bus_UC(nt,Xwind,Xload,cw,cl,Pg);
>>>>> >     if result.results.f>0
>>>>> >         res(j) = result;
>>>>> >         Pg = result.results.Pc([1:19],nt);
>>>>> >         cw = cw+nt;
>>>>> >         cl = cl+nt;
>>>>> >         j= j+1;
>>>>> >     else
>>>>> >         break
>>>>> >     end
>>>>> > end
>>>>> > 
>>>>> > Michał Połecki 
>>>>> > 
>>>>> > -- 
>>>>> > Michał Połecki <P1.jpg><P2.jpg><P3.jpg><P4.jpg>
>>>>> 
>>>>> 
>>>>> 
>>>> -- 
>>>> Michał Połecki
>>> -- 
>>> Michał Połecki <152_periods.jpg>
>> 
> -- 
> Michał Połecki

Reply via email to