- When building algorithms in GAMS. In this case the progress and flow of control is determined by the return codes from the SOLVE statement.
- When building user interfaces around a model. In this case we want to provide informative messages to the user.
- Or both (this was my case: solve is both embedded in an algorithm and I need to report useful messages to the user).
When relying on the Model Status and Solver Status in these cases, we assume that the solver is predictable. Here is a case where the GAMS/Cplex link is sloppy in reporting an iteration limit:
S O L V E S U M M A R Y
MODEL m OBJECTIVE z
TYPE MIP DIRECTION MINIMIZE
SOLVER CPLEX FROM LINE 27
**** SOLVER STATUS 4 TERMINATED BY SOLVER
**** MODEL STATUS 14 NO SOLUTION RETURNED
**** OBJECTIVE VALUE 0.0000
RESOURCE USAGE, LIMIT 226.084 1000.000
ITERATION COUNT, LIMIT 0 100000
ILOG CPLEX Dec 1, 2008 22.9.2 WIN 7311.8080 VIS x86/MS Windows
Cplex 11.2.0, GAMS Link 34
Cplex licensed for 1 use of lp, qp, mip and barrier, with 4 parallel threads.
MIP status(110): error termination, no integer solution
*** CPLEX Error 3019: Failure to solve MIP subproblem.
Error solving MIP subproblem.
Solution aborted due to iteration limit.
The correct solver status would be 2:
**** SOLVER STATUS 2 ITERATION INTERRUPT
Note also that the iteration count is not returned correctly. The link claims zero iterations have been performed. The correct number is 100000. This also means M.ITERUSD is wrong and can not be relied on when reporting back.