10. Beware of Numbering Conventions

If you modify your problem, CPLEX changes not only the dimensions but also the constraint and variable indices of the problem. If your application continues to use the former dimensions and indices, errors may occur. This is especially true when you delete a portion of your problem.

9. Clean House and Try Again

Sometimes inadvertent corruption of an object file creates bugs that are very difficult to isolate. To avoid this, remove all your object files, recompile, and relink your application.

8. Read Your Messages

CPLEX detects many different kinds of errors and generates warnings or error messages about them. To see all of those messages, you need to direct them either to your screen or to a log file. Use the CPXsetintparam (env, CPX_PARAM_SCRIND, CPX_ON) or CPXsetlogfile (env, fp) function calls to send messages to the screen or file, respectively.

7. Check Return Values

Most Callable Library routines return a value that indicates if the routine failed, where it failed, and why it failed. This return value can help you isolate the point in your application where an error occurs.

6. Solve the Problem You Intended

Your application may inadvertently alter the problem and thus produce unexpected results. To check whether your application solves the intended problem, use either the Interactive CPLEX Base System or the diagnostic routines in the check.c file that comes with your CPLEX distribution.

5. Account for the Finite Precision of the Computer

Be aware of precision issues with regards to floating point computation when generating your model. Apparently minor round off errors in computations may lead to unexpected results. For example, consider the following constraints

    1/3 x1 + 2/3 x2 = 1
    x1 + 2 x2 = 3

Under perfect arithmetic, one of these constraints is redundant, and CPLEX has no trouble solving the problem. However, if you round the data to 10 decimal places, you get

    .3333333333 x1 + .6666666667 x2 = 1
    x1 + 2 x2 = 3

These constraints are no longer redundant, and any basis matrix will now be close to singular, making the problem ill conditioned.

4. Try to Reproduce the Problem Using the CPLEX Base System.

If your program behaves unexpectedly, call CPXwriteprob() to write out the problem after it is loaded. Then use the interactive CPLEX Base System to read in the problem, and see if you can reproduce the unexpected behavior.

3. Distinguish between MPS, LP and SAV files When Using the CPLEX Base System.

MPS, LP and SAV files have differences that influence how to interpret the results of the CPLEX base system for debugging. SAV files contain the exact binary representation of the problem as it appears in your program, while MPS and LP files are text files containing less precision for numeric data. And, unless every variable appears on the objective function, CPLEX will probably order the variables differently when it reads the problem from an LP file instead of an MPS or SAV file. With this in mind, SAV files are the most useful for debugging using the base system, followed by MPS files, then finally LP files. Use LP files primarily to examine the problem rather than as input for the base system. Furthermore, try solving both the SAV and MPS files of the same problem using the base system. Different results may provide additional insight into the source of the problem.

In particular, use the following guidelines with respect to reproducing your program's behavior in the base system.

1) If you can reproduce the behavior with a SAV file, but not with a MPS file, this suggests corruption or errors in the problem data arrays. Use the diagnostic routines in the source file check.c to track down the problem.

2) If you can reproduce the behavior in neither the SAV file nor the MPS file, the most likely cause of the problem is that your program has some sort of memory error. Memory debugging tools such as Purify or Insure will usually find such problems quickly.

3) When solving a problem in MPS or LP format, if the CPLEX base system issues a message about a segmentation fault or similar ungraceful interruption and exit, contact CPLEX technical support to arrange for transferring the problem file. The base system should never exit with a system interrupt when solving a problem from a text file, even if the program that created the file has errors. Such cases are extremely rare.

2. Make Good Use of the Debugging Tools in Your Computer.

Commercial debugging tools like Purify and Insure can save huge amounts of development time, paying for themselves within a matter of days. We use them both in the development of the ILOG product line. Make use of these if you have them. If you don't have them, consider buying them. Meanwhile, make use of everything that is available on your machine. For example, Linux has a debugging utility called Electric Fence, and some compilers (e.g. Watcom C/C++) include system calls for checking the integrity of the memory heap.

1. Use the Diagnostic Routines in the Check.c Source File.

The most common bugs in Callable Library applications occur when the program passes invalid data in the argument list of one of the CPLEX routines. The symptom of the problem may occur much later than the cause, and these problems may be difficult to track down since you can't step though an optimized third party library like CPLEX with a debugger. Furthermore, diagnostic routines like Purify or Insure may issue error messages in function inside the Callable Library due to invalid data passed into CPLEX. The diagnostic routines in the check.c source file that come with your CPLEX distribution allow to quickly test the validity of the data passed to the CPLEX problem building and modification routines, quickly identifying the cause of many difficult bugs.