I suggest using MATLAB’s profiler to see where the time is being taken in the
code. It also shows you how many times each line is executed.
Ray
> On Nov 24, 2014, at 10:34 AM, mohd <[email protected]> wrote:
>
> Well understood. Thanks.
>
> For my case, however, i suspect creating candidate generators will have
> minimal effect on the value of the objective function to a point where i
> think they might be ignorable. So, i wanted to test without running the
> candidate generators and compare the objective functions. So, i commented the
> section for running candidate generators in uopf.m. However, i am not seeing
> any improvement in the solution time. So, is there any other section that
> calls for candidate generators than lines 137-176 for the main function
> uopf(). If so, where can i find it? If not, then i am wondering why the
> solution time is still long while we ran the dcopf only once. Thanks.
>
> Kindly,
> Mans
>
> From: [email protected] <mailto:[email protected]>
> Subject: Re: dealing with unit de-commitment
> Date: Wed, 19 Nov 2014 10:33:00 -0500
> To: [email protected] <mailto:[email protected]>
>
> Hi Mans,
>
> First of all, your priority list idea sounds fine in terms of shutting down
> units to reach feasibility, and it is essentially what MATPOWER does in
> uopf()before running the first OPF. And yes, runduopf() does call uopf().
>
> If I understand you correctly, it seems that your objective may be slightly
> different from that of uopf(). It sounds like you are mostly concerned with
> finding a feasible commitment for a problem that has the sum of Pmin greater
> than the load. The purpose of uopf() is (after shutting down enough units to
> make it feasible) to try to find a commitment that will minimize the total
> system cost. I added a step between 1 and 2 in the manual …
>
> Step 1.5 If the sum of the minimum generation limits for all on-line
> generators is less than the total system demand, then go to Step 2.
> Otherwise, go to the next stage, N = N + 1, shut down the generator whose
> average per-MW cost of operating at its minimum generation limit is greatest
> and repeat Step 1.5.
>
> So steps 3 and 4 only enter the picture once we have a feasible DC OPF
> solution. Any generator dispatched at Pmin in this solution is a candidate
> for shutdown. That is, these are the generators that would be dispatched less
> than Pmin if we relaxed the Pmin constraints one at a time. Since shutdown
> decisions are discrete decisions which affect the dispatch of the other
> generators, we try them one at a time. For example, suppose generators A and
> B are the only two dispatched at Pmin in the initial OPF solution, and that
> gen A has lower cost than B, but larger Pmin than B. Without running the OPFs
> for each case, we don’t know which of the following 4 cases has the lowest
> cost:
>
> 1. Gens A and B both on and constrained by Pmin.
> 2. Shut down A and leave B on, possibly at Pmin.
> 3. Shut down B and leave A on, possibly at Pmin.
> 4. Shut down both A and B.
>
> Our heuristic, in step 4 will try running cases 2 and 3, and take the best
> solution from 1, 2, and 3. If the best solution is not 1, it will go on to
> try 4. For large systems, this is very computationally expensive and even so
> does not guarantee the optimal solution. A branch-and-bound or branch-and-cut
> method would be a big improvement.
>
> Ray
>
> --
> Ray Zimmerman
> Senior Research Associate
> B30 Warren Hall, Cornell University, Ithaca, NY 14853 USA
> phone: (607) 255-9645
>
>
> On Nov 18, 2014, at 5:32 PM, mohd <[email protected]
> <mailto:[email protected]>> wrote:
>
> Thanks for referencing the subject section as i have apparently overlooked
> it. I agree with you about the AC OPF but i have decided to use DC OPF for
> the large system. I have a particular question about step-3 and step-4 in
> particular. If i understand correctly from the code, step-3 selects candidate
> generators with high average cost at Pmin that makes the sum of minimum gen
> limits is not anymore higher than served load. However, i do not understand
> step-4 because i thought we should turn off all generators that creates
> infeasibility when sum of Pmin is higher than served load. So, i expected
> that all the expensive generators at Pmin should be turned off and we should
> solve one time and check the total cost then. So, i appreciate a feedback
> about the situation or the reason for solving for each generator in the
> candidate list instead of doing them all at once. Note that for my case, i am
> using DC OPF and i know the case of light loading, we have the expensive
> generators to be close to each others cost. So, if i use a priority list for
> the candidate generators and turn them off till we have Pmin total less than
> served load. In this case, we only run one DC OPF instead of multiple DC OPF.
> This would be very helpful especially for larger systems. Also, i have tried
> to do some modifications to uopf.m and run duopf which i believe when i
> traced it that it calls uopf, i did not see any change in my output. So, i
> also appreciate confirming my understanding about that as well. My final
> objective is simple and i know that it can be done which is run DC OPF only
> once after all expensive units based on priority list satisfies the
> feasibility check of having total Pmin less than the served load.
>
> Thanks again for your cooperation and take care.
>
> Kindly,
>
>
> From: [email protected] <mailto:[email protected]>
> Subject: Re: dealing with unit de-commitment
> Date: Tue, 18 Nov 2014 12:18:50 -0500
> To: [email protected] <mailto:[email protected]>
>
> Hi Mans,
>
> Yes, the unit-decommitment is handled in uopf.m. And, yes, it can be very,
> very slow, especially for large systems. It is a very brute-force method. The
> basic algorithm is as described in Chapter 8 in the User’s Manual
> <http://www.pserc.cornell.edu/matpower/manual.pdf>, with the exception that
> it actually does as you proposed in (1) before attempting the first OPF in
> Step 2. (I guess I need to update that in the manual)
>
> You could certainly code your own commitment algorithm using any number of
> heuristics. For the AC OPF the problem is mixed-integer non-linear program,
> so finding the optimal value is non-trivial, but I’m sure you can find a
> pretty good heuristic that is much faster than uopf.m.
>
> Ray
>
>
>
> On Nov 17, 2014, at 4:04 PM, mohd <[email protected]
> <mailto:[email protected]>> wrote:
>
> Dear all,
>
> I was recently faced with a system that experiences a negative lambda. Upon
> further analysis, this happens when minimum generation exceeds load, which is
> typical in a Winter season. So, i have tackled it by using the unit
> de-commitment algorithm provided by matpower. However, i was faced with an
> expensive computational time that takes almost 30 minutes to solve one
> instance of DCOPF. So, i have several ways to resolve the issue and i am
> wondering about the possibility of implementing these possibilities into the
> unit de-commitment scheme to save some computational time even if that means
> a less optimal solution for my case. The following are the approaches:
>
> 1) De-commit units and check against the sum of the minimum of generators
> till the issue is resolved without running the DCOPF each time.
> 2) Turn units sequentially using a priority list without looking into
> different combinations. I am not sure how matpower does that but i suspect
> that matpower tries different combinations of generators that are turned ON
> and OFF and saves only the cheapest objective function (the minimum total
> cost). If so, this is computationally expensive, especially for large systems
> and can create computational infeasibility.
>
> So, what is the case file that performs the unit de-commitment. Is it the
> uopf.m? If so, i need someone to explain to me the algorithm because some
> commands that are used for the de-commitment decision are not familiar to me.
> Also, I appreciate any feedback in regard to the subject issue. Thanks for
> your cooperation in advance and take care.
>
> Kindly,
