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 <mansour1...@hotmail.com> 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: r...@cornell.edu <mailto:r...@cornell.edu> > Subject: Re: dealing with unit de-commitment > Date: Tue, 18 Nov 2014 12:18:50 -0500 > To: matpowe...@list.cornell.edu <mailto:matpowe...@list.cornell.edu> > > 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 <mansour1...@hotmail.com > <mailto:mansour1...@hotmail.com>> 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,
