Slow solution using MIP

Problems with modeling
Post Reply
serch199
User
User
Posts: 10
Joined: 1 year ago

Slow solution using MIP

Post by serch199 »

Hola a todos
Tengo un problema, estoy resolviendo un modelo de UC consiente de fallas en líneas o generadores, pero mi problema es que el modelo tarda mucho en obtener una solución cuando se utilizan sistemas eléctricos “grandes” (300 buses, etc.).
Adjunto mi código y los datos que utilizo para el sistema de 300 buses, si alguien lo puede revisar y decirme por que tarda tanto, o que errores estoy cometiendo
Muchas gracias.


Hello everyone
I have a problem, I am solving a Unit Commitment model aware of faults in lines or generators, but my problem is that the model takes a long time to obtain a solution when using "large" electrical systems (300 buses, etc.).
Attached is my code and the data I use for the 300 bus system, if someone can review it and tell me why it takes so long, or what mistakes I am making.
THANKS.
Corre_iny_CON_Perdidas.gms
trdat5.gdx
Fred
Posts: 372
Joined: 7 years ago

Re: Slow solution using MIP

Post by Fred »

Hi,

Running with default settings (see Corre_iny_CON_Perdidas_baseline.log), the root relaxation already takes already 334 seconds on my machine. Afterwards, Cplex spends ages with the generation of flow cover cuts (I killed the job after half an hour).
With that said, I tried to run the model with CPLEX options

Code: Select all

startalg 4
flowcovers -1
mipemphasis 5 
and got a solution (within the specified optimality gap of 0.1%) after 7 minutes (see Corre_iny_CON_Perdidas_8threads_startalg4_flowcovers-1_mipemphasis5.log).
For details about those GAMS /CPLEX options, please see the GAMS/CPLEX Solver Manual.
If you are not familiar with how to set solver options in general, please have a look at this chapter of the documentation


Another thing I noticed is that the model scaling is very bad:

Code: Select all

--- Range statistics (absolute non-zero finite values)
--- RHS       [min, max] : [ 1.800E-01, 2.353E+04] - Zero values observed as well
--- Bound     [min, max] : [ 1.000E+00, 1.000E+00] - Zero values observed as well
--- Matrix    [min, max] : [ 5.421E-20, 1.000E+06]
As a rule of thumb, you want the non-zero coefficients in your model to be relevant. Solvers work with internal tolerances (many of them in the range of 1e-6). Now coefficients as small as 1e-20 can a) become pretty meaningless and b) make the model numerically challenging.

I hope this helps!

Fred
Corre_iny_CON_Perdidas_baseline.log
(49.48 KiB) Downloaded 71 times
serch199
User
User
Posts: 10
Joined: 1 year ago

Re: Slow solution using MIP

Post by serch199 »

Hi Fred

Thank you very much for taking the time to review my code, I was very struck by the fact that the model is very badly scaled, and my question is what is the correct way to scale it, or if you could give me an example of how to correct that or what I'm doing wrong in my code.


Or also if there is a way to "ignore or take as zero value" those coefficients that you mention that are so small (1e-20).

I'm sorry if my questions are very silly, but I'm new to gams.

Again thank you very much for your time
Regards
Fred
Posts: 372
Joined: 7 years ago

Re: Slow solution using MIP

Post by Fred »

Hi,

The McCarl Newsletter Volume 47 has a good introduction to model scaling and also gives some pointers to other places (like the GAMS documentation) where model scaling is discussed: https://www.gams.com/newsletter/mccarl/ ... _no_47.pdf

There are diffreent ways to detect where those small coefficients actually come from (if you do not know that already). One of them is for example using Cplex option datacheck=2 which will activate Cplex' data consistency checking and modeling assistance and give the following output:

Code: Select all

CPLEX Warning  1010: Detected nonzero <= CPX_MINBOUND at constraint 'eq3_2(1,1)', variable 'LM(1,1)'.
CPLEX Warning  1045: Detected nonzero <= the maximum value of either CPX_PARAM_EPRHS or CPX_PARAM_EPOPT at constraint 'eq3_2(1,1)', variable 'LM(1,1)'.
CPLEX Warning  1010: Detected nonzero <= CPX_MINBOUND at constraint 'eq3_2(1,1)', variable 'LM(2,1)'.
CPLEX Warning  1045: Detected nonzero <= the maximum value of either CPX_PARAM_EPRHS or CPX_PARAM_EPOPT at constraint 'eq3_2(1,1)', variable 'LM(2,1)'.
CPLEX Warning  1010: Detected nonzero <= CPX_MINBOUND at constraint 'eq3_2(1,1)', variable 'LM(4,1)'.
[...]
Best,
Fred
serch199
User
User
Posts: 10
Joined: 1 year ago

Re: Slow solution using MIP

Post by serch199 »

Hi Fred

Thank you very much for taking the time to review my code, I will pay attention to the points you mentioned.
Don
User
User
Posts: 11
Joined: 1 year ago

Re: Slow solution using MIP

Post by Don »

Hi there,

I am having very similar challenges with my model. It compiles forever and never stops until it times out or runs out of memory.

Kindly assist anyone.
User avatar
bussieck
Moderator
Moderator
Posts: 1033
Joined: 7 years ago

Re: Slow solution using MIP

Post by bussieck »

A few comments:

This is a MIP of substantial size:

Code: Select all

--- TEP.gms(387) 1612 Mb[FIL:"C:\Users\mbuss\Downloads\TEP.gms",387,0]
---   868,092 rows  347,668 columns  2,775,127 non-zeroes
---   173,568 discrete-columns
--- Range statistics (absolute non-zero finite values)
--- RHS       [min, max] : [ 2.911E+00, 4.189E+03] - Zero values observed as well
--- Bound     [min, max] : [ 2.000E-01, 1.320E+01] - Zero values observed as well
--- Matrix    [min, max] : [ 2.000E-01, 3.854E+10]
The range of matrix coefficients is large (~1e11) as well as the objective function about (~1e10). This can be a sign for poor scaling of the model.

A single bigM (M /1000/) can often be improved by looking at the data involved in the expression.

Sorry, not much to really help.

-Michael

PS The model actually does not compile forever (in GAMS lingo "compile" has a very specific meaning, see https://www.gams.com/41/docs/UG_GamsCal ... ll_TwoPass), the solver (you actually did not say what solver you used) takes forever to solve this model instance.
Post Reply