0

I am using GLPK and I am struggling in understanding why an upper bound constraint is not respected. I have something like this:

param n0;
param n1;
param n2;
param start_0{i in 0..n0};
param end_0{i in 0..n0};
param start_1{i in 0..n1};
param end_1{i in 0..n1};
param start_2{i in 0..n2};
param end_2{i in 0..n2};

var y0 {k in 0..n0} binary; 
var y1 {k in 0..n1} binary;
var y2 {k in 0..n2} binary;

[...]

minimize obj: (sum{k in 0..n2}(end_2[k]*y2[k] + 600*y2[k])  - (sum{k in 0..n0} (start_0[k]*y0[k])));

[...]

s.t. c1: (sum{k in 0..n2} (end_2[k]*y2[k] ) - (sum{k in 0..n0} (start_0[k]*y0[k] ))) <= 7000;

s.t. c2_1: sum{k in 0..n0} y0[k] = 1 ;
s.t. c2_2: sum{k in 0..n1} y1[k] = 1 ;
s.t. c2_3: sum{k in 0..n2} y2[k] = 1 ;

[...]
solve;

[...]

printf (sum{k in 0..n2} (end_2[k]*y2[k] ) - (sum{k in 0..n0} (start_0[k]*y0[k] )));

The last printf gives me 7200. But the constraint c1 above should ensure that the difference is not greater than 7000.

The solver output is the following:

GLPK Integer Optimizer, v4.65
7 rows, 353 columns, 1332 non-zeros
353 integer variables, all of which are binary
Preprocessing...
6 rows, 353 columns, 1059 non-zeros
353 integer variables, all of which are binary
Scaling...
 A: min|aij| =  1.000e+00  max|aij| =  1.625e+09  ratio =  1.625e+09
GM: min|aij| =  9.998e-01  max|aij| =  1.000e+00  ratio =  1.000e+00
EQ: min|aij| =  9.996e-01  max|aij| =  1.000e+00  ratio =  1.000e+00
2N: min|aij| =  7.561e-01  max|aij| =  1.000e+00  ratio =  1.323e+00
Constructing initial basis...
Size of triangular part is 6
Solving LP relaxation...
GLPK Simplex Optimizer, v4.65
6 rows, 353 columns, 1059 non-zeros
      0: obj =  -2.232000000e+05 inf =   1.329e-04 (2)
      2: obj =   6.210000000e+04 inf =   0.000e+00 (0)
*     5: obj =   7.097321429e+03 inf =   0.000e+00 (0)
OPTIMAL LP SOLUTION FOUND
Integer optimization begins...
Long-step dual simplex will be used
+     5: mip =     not found yet >=              -inf        (1; 0)
+   272: >>>>>   1.320000000e+04 >=   1.140000000e+04  13.6% (237; 2)
+   304: mip =   1.320000000e+04 >=     tree is empty   0.0% (0; 477)
INTEGER OPTIMAL SOLUTION FOUND
Time used:   0.0 secs
Memory used: 0.8 Mb (851464 bytes)
Display statement at line 22
[...]
Model has been successfully processed

What I am doing wrong? Thanks a lot for your help,

Gioia
  • 81
  • 1
  • 9
  • Make sure the model was optimal. Study the solver log. – Erwin Kalvelagen Jun 15 '21 at 08:01
  • thanks @ErwinKalvelagen, I'll add the output in my question. An optimal solution is found. – Gioia Jun 15 '21 at 08:03
  • (1) That log shows an objective of 13200. (2) You repeat this long expression 3 times. I would introduce a single equality constraint: `z = (sum{k in 0..n2} (end_2[k]*y2[k] ) - (sum{k in 0..n0} (start_0[k]*y0[k] )))` and from there on use `z`. No duplicates is less typing and makes the model smaller in terms on nonzero elements. – Erwin Kalvelagen Jun 15 '21 at 10:01
  • So we have now 3 different numbers: 7000, 7200 and 13200. This is a big mess. – Erwin Kalvelagen Jun 15 '21 at 10:26
  • Yes, the objective function is a bit different, there is a weight in it, I haven't reported it here for sake of simplicity, but it looks like this: `(sum{k in 0..n2}(end_2[k]*y2[k] + 600*y2[k]) - (sum{k in 0..n0} (start_0[k]*y0[k])));`. So, it is normal that the objective function and my constraint produce different values. Still, I don't understand why the constraint is not respected. – Gioia Jun 16 '21 at 12:48
  • The strange thing, also, is that if I lower down a bit the constraint max value, from 7000 to 6800 for example, it works. On which basis? – Gioia Jun 16 '21 at 12:49
  • I don't have a complete picture, but if you are sure you hit a bug, you may want to submit a bug report to the glpk mailing list. – Erwin Kalvelagen Jun 16 '21 at 14:13
  • Thanks Erwin. I am not sure of this being a bug, but maybe I can ask them to have a feedback. – Gioia Jun 17 '21 at 15:09

0 Answers0