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.

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

```
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:

```
--- 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_8threads_startalg4_flowcovers-1_mipemphasis5.log (23.4 KB)

Corre_iny_CON_Perdidas_baseline.log (49.5 KB)

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

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/archive/mccarl_newsletter_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:

```
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

Hi Fred

Thank you very much for taking the time to review my code, I will pay attention to the points you mentioned.

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.

A few comments:

This is a MIP of substantial size:

```
--- 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_GamsCall.html#UG_GamsCall_TwoPass), the solver (you actually did not say what solver you used) takes forever to *solve* this model instance.