So runuopf() begins by running an OPF with all generators turned on, with active power dispatches limited by PMIN and PMAX. Any unit that is dispatched at PMIN (and would be dispatched lower if the limit were relaxed) is said to have a binding PMIN limit and is therefore considered as a candidate for shutdown. It re-runs the OPF with each of these candidates shut down (one at a time) and continues the process with the one that produced the greatest decrease in objective function … terminating when the objective is not decreased by shutting down any of the units dispatched at PMIN.
So on second thought, since your "shunt generators” are always dispatched at PMIN (since PMIN = PMAX), they are always candidates for shutdown, so long as the nodal price of active power is positive. This means that runuopf() may actually give you a decent approximation to the solution of the problem after all. The last condition (positive nodal price) is necessary to ensure that it is the PMIN limit that is binding, not the PMAX limit. The binding limit is the one that would alter the solution if it were relaxed. However, runuopf() still requires that the problem be feasible with all generators turned on. It will not be able to shut down units to turn an infeasible problem into a feasible one … only to decrease the cost of a feasible problem. Ray On Sep 9, 2020, at 9:33 PM, yangyang <[email protected]<mailto:[email protected]>> wrote: Thank you for your suggestion Prof Ray. Actually I am still learning about the mechanism of uopf() and I dont really understand what binding Pmin limits means. In the attached files, if the cases with and without shunt generators have the same limits of voltage magnitude, the case with shunt generators will have less cost using runuopf() and it seems that the shunt with -8Mvar Qg will be shut down to avoid voltage magnitude violation. I dont know if this is the correct result. And thank you for your invitation, but I am a newbie at optimization. I really doubt if I could help in creating a convenient and integrated interface like runpf() and runopf() to implement mixed integer programming using other solvers. There is still quite a lot for me to learn. "MATPOWER discussion forum" <[email protected]<mailto:[email protected]>>; 2020年9月9日(星期三) 晚上9:57 "MATPOWER-L"<[email protected]<mailto:[email protected]>>; Re: optimal power flow with unit commitment using mixed integer programming Unfortunately, I do not believe runuopf() will work for this problem, since it uses heuristics to de-commit units one at a time based only on binding Pmin limits, not on binding reactive power limits, which is what you would need. I suppose you could modify uopf() to look at both, but in the end you still have a very crude and inefficient heuristic for dealing with the binary decisions, with no guarantees on the final optimality gap. The proper way to solve this problem would be to create an interface in MP-Opt-Model for a mixed-integer nonlinear programming solver. Knitro has these capabilities, but they have not (yet) been implemented in MP-Opt-Model’s Knitro interface. We have nlps_knitro(), but we need a minlps_knitro(). There is also a suggestion in the issue tracker to include an interface for Bonmin<https://github.com/MATPOWER/mp-opt-model/issues/1> which also handles MINLP problems. Both would be very welcome and useful additions. Any chance you have time to work on this? I’d be happy to lend my support. Ray
