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 
<980182...@qq.com<mailto:980182...@qq.com>> 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" <r...@cornell.edu<mailto:r...@cornell.edu>>;
2020年9月9日(星期三) 晚上9:57
"MATPOWER-L"<matpowe...@list.cornell.edu<mailto:matpowe...@list.cornell.edu>>;
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




Reply via email to