Wednesday, February 27, 2013

Repeating messages

Solvers sometimes spit out messages that are basically similar. Here is an example of a list of a few million messages (literally!):

MOSEK Warning 53     : A numerically large upper bound value 2.3e+009 is specified for variable 'alloc(12463682,barl_h)' (2).
MOSEK reports warning number 53: A numerically large upper bound value 2.3e+009 is specified for variable 'alloc(12463682,barl_h)' (2).
MOSEK Warning 53     : A numerically large upper bound value 2.2e+009 is specified for variable 'alloc(12463684,barl_h)' (20).
MOSEK reports warning number 53: A numerically large upper bound value 2.2e+009 is specified for variable 'alloc(12463684,barl_h)' (20).
MOSEK Warning 53     : A numerically large upper bound value 2.0e+009 is specified for variable 'alloc(12473679,barl_h)' (38).
MOSEK reports warning number 53: A numerically large upper bound value 2.0e+009 is specified for variable 'alloc(12473679,barl_h)' (38).
MOSEK Warning 53     : A numerically large upper bound value 2.3e+009 is specified for variable 'alloc(12473683,barl_h)' (56).
MOSEK reports warning number 53: A numerically large upper bound value 2.3e+009 is specified for variable 'alloc(12473683,barl_h)' (56).
MOSEK Warning 53     : A numerically large upper bound value 3.6e+009 is specified for variable 'alloc(12473684,barl_h)' (74).
MOSEK reports warning number 53: A numerically large upper bound value 3.6e+009 is specified for variable 'alloc(12473684,barl_h)' (74).
MOSEK Warning 53     : A numerically large upper bound value 4.2e+009 is specified for variable 'alloc(12473685,barl_h)' (92).
MOSEK reports warning number 53: A numerically large upper bound value 4.2e+009 is specified for variable 'alloc(12473685,barl_h)' (92).
MOSEK Warning 53     : A numerically large upper bound value 1.4e+009 is specified for variable 'alloc(12483674,barl_h)' (110).
MOSEK reports warning number 53: A numerically large upper bound value 1.4e+009 is specified for variable 'alloc(12483674,barl_h)' (110).
MOSEK Warning 53     : A numerically large upper bound value 2.4e+009 is specified for variable 'alloc(12483683,barl_h)' (128).
. . . .

In general the n-th message has very little additional value if n is  large. A better approach is to stop issuing those similar messages after say n=10 and then just report an aggregate e.g. how many times this situation happened.

The next example is almost what I would like to see in this respect. Missing is the total number domain errors when loading this symbol.

   1  set i /j1*j1000/;
   2  alias (i,j);
   3  parameter a(i,j);
GDXIN   C:\projects\tmp\ide\x.gdx
--- LOAD  a = 3:a
**** Domain errors for symbol a
**** Only the first 10 errors are shown
     i1.i1
     i1.i2
     i1.i3
     i1.i4
     i1.i5
     i1.i6
     i1.i7
     i1.i8
     i1.i9
     i1.i10
   5  $loaddc a
****          $649
**** 649  Domain violation when loading from GDX file

4 comments:

  1. I think you have reported this issue before long time ago. I should have implemented something so the number warnings is limited.

    In other words you seem to hit bug or using a old version. Can you in any way make the model available to us, so I can get it fixed.

    ReplyDelete
  2. The model is too large to send, but this can be reproduced just by introducing a large bound on any variable in any model.

    E.g.

    set i /i1*i1000000/;

    positive variable x(i);
    x.up(i) = 1e9;

    variable z;

    equation e;
    e.. z =e= sum(i,x(i));

    model m /e/;
    option lp=mosek;
    solve m using lp minimizing z;

    ReplyDelete
  3. It is fixed in the upcoming GAMS release that features MOSEK v7. Stefan Vigerske of GAMS has check that it only produces 5 warnings.

    ReplyDelete
  4. Great. That will make solution times much faster!

    ReplyDelete