There is nothing here that is necessarily an error, though it’s not clear to me
why you are modifying the load profile after loading it with getprofiles(), as
opposed to modifying the profile file itself, though I’m sure there could be
valid reasons to do it that way, depending on the context.
But I still think answering my other question is critical for tracking down
what is going on. Namely, have you confirmed that the load profile is not being
applied? Is the generation schedule in the result completely flat?
Ray
> On Sep 29, 2018, at 2:22 AM, Michal Polecki <[email protected]>
> wrote:
>
> Dear Profesor,
>
> I can share it. It is quite complicated though. I'll send you 4 files
> necessary for obtaining the load profile.
>
> To use the files in Matpower I wrote a code like this:
>
> loadbuses = MMloadbuses(mpc);
> profiles = getprofiles('MM_ex_load_profile_118bus');
> profiles.rows = loadbuses;
> profiles.values(:,1,:) = MMloads_profiles(mpc,nt);
>
>
> Can you spot any mistakes?
>
> Best Regards,
> Michał Połecki
>
>
> On 09/28/18 16:02, Ray Zimmerman <[email protected]> wrote:
>>
>> 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]
>>> <mailto:[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]
>>> <mailto:[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] <>> 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] <>> 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] <>> 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] <>> 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
>>
> --
> Michał Połecki
> <MMloads_profiles.m><MMloadbuses.m><MMobc_system_godz.mat><MM_ex_load_profile_118bus.m>
