random 'matrix error' inconsistent across GAMS installations

Problems with modeling
Post Reply
Posts: 20
Joined: 3 years ago

random 'matrix error' inconsistent across GAMS installations

Post by pecenak21 » 2 months ago


Lately I have noticed a strange error on disparate projects (maybe 1 of every 100 runs, but random). The error is a 'Matrix error - bounds on discrete variables have to be integer'. Two things make this error strange: (1) my bounds are integer. I know this because they are set in an iterative loop from a previous GAMS solve using an integer variable solution (i.e. newVariable.fx=myVariable.l). I have even tried applying a round operation to this hand-off. (2) We have 3 servers running GAMS 35.1, when I try it on different servers with the same GAMS codebase, it works on all but 1. It isn't the server though, as this same thing has happened on a different server with a different model.
Further, I have noticed something as small as changing a single (completely unrelated) input parameter from 11.99 to 12 can cause this behavior. I have attached a picture of the issue below.
My first thought was precision with the integer variable( i.e. eprhs), but again, I tried the round functionality and no dice. Please advise as this is causing trouble for our commercial customers.


User avatar
Posts: 663
Joined: 5 years ago

Re: random 'matrix error' inconsistent across GAMS installations

Post by bussieck » 2 months ago


newVariable.fx=myVariable.l does not guarantee you integer bounds. The .l is subject to solver tolerances (often 1e-6) and hence you can set the bounds of a discrete variable to a non-integer value. The round should have helped though. Also, do you check the model status being 1 (optimal) or 8 (integer) before you continue to iterate. Your "solution" might be intermediate non-integer or infeasible. Here is the list of possible model status values: https://www.gams.com/latest/docs/UG_GAM ... _21_status. Since the identical optimization path inside a solver is only guaranteed on the same machine with the same options (unless some opportunistic options have been set) it is understandable that you get different results on different machines.

Try to capture the GAMS database when this happens and analyze the variable bounds offline. So after the solve check for execution errors, dump the entire GAMS database to a GDX file and exit:

Code: Select all

maxExecError = 1e6;
solve xenopt_model using mip minimizing obj;
  execute_unload 'all.gdx';
  abort 'stop';
Note that if the values of the bounds display as integers does not mean that they are integers. Load the bounds into a GAMS program and calculate: xlodiff = x.lo - round(x.lo); display$xlodiff 'xlodiff is nonzero', xlodiff; (same with up). I guess that you will see some small non-zero values in the display.


Post Reply