Unit commitment constraints

[pyth...@gmail.com]

Hi everybody,

I struggling with a efficient formulation of an unit commitment constraint.

If I am not wrong, from a mathematical point of view it is simple - either a unit is on or off.

However, the computational effort of my own implementation in Pyomo is extremely long.

[Even for 3 days - 72 hours - CBC is running and running.] 

For testing I switched off all ramping constraints, with same "results".

I am quite sure that the problem arise after implementing the constraints - it was much faster before.

I am not sure wether I made a mistake or the problem needs so many resources. 

Maybe there is an easier way than defining a  binary (0,1) control vector. 

Pls. see here the respective equations, maybe someone can help (again).

Have a nice weekend

Frank

----

model.r_S = Var(model.T,model.N,bounds = (0,1), within=Binary) # on/off vector for TPP

"model.unit defined as scalar"

"model.gV_S[T,"TPP",N]  power generation of TPP at node N in T"

def constraint_upper_bound_generation_rule(model, T, N, S):

if S == "TPP":

return model.gV_S[T,S,N] <= model.r_S[T,N] * model.gBar_S[S,N]

...

model.constraint_upper_bound_generation = Constraint(model.T, model.N, model.S, rule=constraint_upper_bound_generation_rule, doc='Constraint upper bound of generation ')

def constraint_lower_bound_generation_rule(model, T, N):

return model.gV_S[T,"TPP",N] >= model.r_S[T,N] * model.unit

model.constraint_lower_bound_generation = Constraint(model.T, model.N, rule=constraint_lower_bound_generation_rule, doc='Constraint lower bound of TPP generation ')

[Watson, Jean-Paul]

The topic of computationally efficient mixed-integer programming formulations for unit commitment is rather extensive, and it is not surprising that a straightforward formulation could indeed be very difficult for CBC.

 

A recent survey can be found here: http://www.optimization-online.org/DB_HTML/2018/11/6930.html

 

jpw

--
You received this message because you are subscribed to the Google Groups "Pyomo Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pyth...@gmail.com]

THX

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo...@googlegroups.com.

[pyth...@gmail.com]

Hi JPW,

in case you see my massage I´d be happy to get additional support.

First of all, the paper you mentioned is very fruitful and helped me a lot to understand at least the next piece of the puzzle.

I now have implemented unit commitment and everything runs well - however quite slow with CBC.

If I add the a cost term for all start ups, the solver runs and runs.

Do you have any further advice for simplifying the formulation of unit commitment costs. Maybe by reformulating the binary in reals?

Thank you in advance

Frank

On Friday, May 3, 2019 at 7:42:48 PM UTC+2, JPW wrote:

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo...@googlegroups.com.

[Watson, Jean-Paul]

The topic of unit commitment formulations is outside the scope of the pyomo forum, despite several folks on the forum that know something about the topic.

 

But I will note that even if you have a state-of-the-art UC formulation (e.g., to address startup cost computation efficiently), even commercial solvers such as Gurobi and CPLEX can have trouble with modestly sized unit commitment problem instances. Thus, cbc struggling is not particularly surprising.

To unsubscribe from this group and stop receiving emails from it, send an email to pyomo-forum...@googlegroups.com.

[pyth...@gmail.com]

Thank you JPW,

indeed it is not really a topic for this forum. But you answer help me to understand better the importance of performance. Best

Frank

[Sean Anderson]

I would take a look at the formulation examples at https://yalmip.github.io/example/unitcommitment/ as Johan is an expert in optimization, so he tends to have efficient formulations.

[Frank Meissner]

Thank you Sean, very inspiring!