Performance World [ Performance World Home | Board | Tools | PerformanceLib | Links | GamsWorld group | Search | Contact ]

Benchmarking the GAMS Branch-and-Cut-and-Heuristic Facility

by Alexey Koptsevich

We present benchmarking of the GAMS Branch-and-Cut-and-Heuristic Facility (hereafter BCHF) on a set of test instances, provided by Ortega and Wolsey (Ortega F. & Wolsey L., Networks, 41, 2003, no. 3, 143--158; more detailed description of model instances can be found in their discussion paper). We developed a set of programs to port the test instances to GAMS framework, and compared performance of different solvers (CPLEX, XPRESS, XA) to the performance of CPLEX with BCHF enabled. Please first read the Introduction, where we explain the explicit goals of this project and briefly describe the final products. Then, if you want to

1. Introduction

The test instances we used are available at personal webpage of L. Wolsey, two archives contain single-source and multi-source instances. They are also mirrored at this website (single-source and multi-source). There are 83 instances in total, 45 single-source and 38 multi-source ones (the single-source archive actually contains 46 instances, but we discarded one of them, h80x6320, because of the presumable errors in its data files). The archives contain the data of each model instance (hereafter source instances) in both XPRESS and MPS formats, mutual consistency of which we take for granted.

The project pursued the following goals:

  1. Create a common GAMS model file which would allow to load data (matrices) of each instance as include-files.
  2. Translate data (matrices) of each model instance from XPRESS to GAMS format and arrange them as a set of include-files (hereafter translated instances).
  3. Automatically convert model instances from MPS to GAMS format (hereafter converted instances).
  4. Check matrix statistics of both translated and converted instances to ensure accuracy of translation.
  5. Run GAMS on both translated (without BCHF) and converted model instances to ensure accuracy of translation, at RMIP stage -- for all instances, at MIP stage -- for easy instances only.
  6. For hard instances (not solved to optimality by CPLEX without BCHF during specified interval of time), determine at which values of the objective function we should start to apply cuts and heuristics provided by BCHF to keep performance optimal.
  7. Use this set of instances to compare performace of various solvers (in particular, CPLEX, XPRESS, and XA were used in our test runs) to performance of CPLEX with cuts/heuristics provided by BCHF.
If you wish to repeat our processing, the full set of the developed programs is available for download. The files are packed in several archives:
  1. bchf-scripts.tgz -- a set of Unix shell scripts and GAMS programs to perform steps I--VI from the list above. The scripts are tested working on Linux platform. For description of these programs see Sec. 2.
  2. bchf-inst.tgz -- a set of GAMS include-files with model instances (prepared at step II).
  3. bchf-conv.zip -- a set of converted gms- and gdx-files with model instances (prepared at step III).
  4. bchf-gms.tgz -- a set of GAMS model files (prepared at step I) which, together with include-files, allow to repeat step VII on all platforms supported by GAMS. For description of these programs see Sec. 3.
  5. bchf-agr.tgz -- source files (for Grace) of graphs presented in Sec. 4.

2. Translating model instances

In this Section we describe how to process the set of test instances to translate them to the GAMS framework and make sure that the translation was performed correctly. We describe each program and give examples of typical usage.

The archive bchf-scripts.tgz contains the following files:

  1. togams -- a shell script to convert model instances from XPRESS format to GAMS format
  2. rungams -- a shell script to run GAMS on specified instances for a specified period of time
  3. compgams -- a shell script to compare results of different runs of GAMS on a set of instances
  4. runall -- a shell script to run scripts togams, rungams, compgams and perform some other processing in one command
  5. param.conf -- a configuration file for all the above scripts in shell format
  6. printnice.gms -- a GAMS script to convert instances of type "2" to nice-looking format
  7. bchfcnet.gms -- a general GAMS model file for use with rungams. Inc-files are called via directive "$include".
  8. bchdicut.inc - a GAMS model file which implements dicut inequalities.
  9. 13rm -- an auxiliary script for conversion of ASCII files from DOS to UNIX format (used by runall).

2.1. runall

The program runall is designed to be an interface to all programs from this archive. You do not need to run other programs if you just want to repeat the tasks I--VI from the list n Sec. 1. You can accomplish these tasks altogether or step by step.

Syntax: runall [steps]

steps is a string containing one or more letters from the list below. If the given letter is included, the corresponding step is performed. If parameter steps is omitted, the default configurations from param.conf is used. There are 10 steps:

  1. Preparations. There is a separate directory for each instance in the source archive. Each directory contain XPRESS-file, MPS-file and accompanying ASCII data files. We retain this structure while we do translation and cheking of instances. At this step, in the directory of each instance all ASCII files are converted from DOS to Unix text format; additional copies of param.conf for RMIP-relaxed and other modes of operation are created; hardlinks to commonly used files are created, etc.
  2. Translate instances from XPRESS format to GAMS with togams; to complete translation of instances of type "2", GAMS is called with printnice.gms.
  3. Solve translated instances with "rungams optfile=0" (i.e., without BCHF).
  4. Solve translated instances with "rungams optfile=1" (i.e., with BCHF).
  5. Convert instances from MPS format to GAMS format: mps2gms (which is a part of GAMS distribution) is called to convert all instances automatically. Then all instances are run at RMIP stage just to create corresponding gdx-files.
  6. Solve converted instances with rungams.
  7. Utilize compgams to comapre results of different runs of rungams, e.g., runs of the translated and converted instances.
  8. Determine startcut and startheur parameters for hard instances. To use BCHF effectively, it should not be called from the very beginning if the solver provides its own BCHF, as CPLEX does. We start to call BCHF when the solver is finished with the root node. The values of objective function reached when the root node is finished are calculated at this step using "rungams nodlim=1". They are then saved in data.gms.
  9. Run converted and translated instances in RMIP mode to compute matrix statistics and RMIP objective values.
  10. Copy model instances in GAMS format, converted gms- and gdx-files to the directory specified in param.conf.
  11. Compare matrix statistics of the translated and converted instances.
For all programs called via runall all parameters are set from param.conf. You can get more information of what is going on at the steps bcdefgh by reading the descriptions of param.conf, rungams, compgams, and togams. We dwell on matrix statistics comparison (step "k") in Sec. 2.7.

2.2. togams

The program togams translates model instances from XPRESS forrmat to GAMS format.

Syntax: togams datatype filename.xxx

datatype is two-digit specification of the model type, the first digit is a number in the range 1--8, the second one is an arbitrary alphanumeric symbol. The datatype must be defined in param.conf. Model types are the following:

  1. Instances with variable costs equal to zero (Steiner trees; 8 instances).
  2. Instances with multiple cost options per arc; the data reside in MPS-file (multi-segment; 2 instances).
  3. Instances with multiple cost options per arc; the data reside in separate ASCII files (multi-segment; 6 instances).
  4. Instance with fixed or variable cost equal to zero for some open arcs (from MIPLIB; 1 instance).
  5. Various types of instances (grid, complete graph, lot-sizing, planar, random; 49 instances).
  6. Instances with multiple cost options per arc; the number of cost options is not specified explicitly (series-parallel; 9 instances).
  7. Instances of type "complete graph and one node" (Hochbaum; 5 instances).
  8. Instances of type "complete graph and one node" with forbidden flow from any node to itself (Hochbaum; 3 instances).
All instances from the Table in Annex B of the discussion paper are present in the source archives, with the exception of h80x6320, and h50x2450d is added. The above classification does not necessarily follow one in the paper of Ortega and Wolsey because the instances were classified based on the data representation in XPRESS-files, not on the structure of the problem. The predefined data types are listed in param.conf, they cover all instances in the source sets. Declaring your own types can be useful if you want to work only with specific instances or specific instance types, and still use the interface of runall.

filename.xxx should be a model file in XPRESS format. The filename extension is arbitrary but should be of 3 symbols length, default extension is "mod". Translated GAMS-file is stored in the same directory as a source XPRESS-file.

2.3. rungams

The program rungams runs specified model instance(s) for a specified period of time.

Syntax: rungams filename(s).xxx

filename(s).xxx is a list of inc-files prepared by togams.

First, RMIP problem is solved by gams by performing runs with infile (default is bchfcnet.gms) with each of filename(s).xxx. Then, if the parameter cpulim is non-zero, gams is run for MIP problem. In both cases, gams command line parameters are set via parameter gamspar.

During computations the running time (either elapsed time or CPU time; set by parameter timecounter) of gmscp_ux.out reported by ps is monitored (every check seconds). One can set additional parameters for ps via parameter psopts (e.g., to account for time consumed by child processes of gams). Once the running time reaches cpulim, the signal INT is sent to the process gmscp_ux.out. Then rungams waits for the initial gams process to complete, extracts output information from the tracefile and appends it to the output file.

The name of the output file is formed from two parameters: infile.extt (default is bchfcnet.tab). It is started with 3 header lines, each of which begins with the comment symbol "#". For each instance, the following data are reported:

  1. A datatype to which the instance belongs.
  2. Instance name.
  3. Optimal objective value of the RMIP problem.
  4. Minimum objective value (this and remaining fileds relate to the MIP problem).
  5. Best bound.
  6. Relative gap.
  7. Number of nodes.
  8. Elapsed time reported in the GAMS listing file.
  9. Wall time reported by time.
  10. User time reported by time.
  11. Time consumed by gmscp_ux.out reported by ps.
  12. Value of psopts and command line parameters of ps used to monitor execution time.

2.4. compgams

compgams compares results of runs of rungams on a set of instances.

Syntax: compgams out_file in_file(s)

in_file(s) are output files of rungams, minimum 2 names must be given. The first file is considered to be a reference file, only model instances from this file participate in the comparison.

It is determined by the parameter objvcomp, which of the values (RMIP objective, MIP objective, best bound, gap) should be compared. The result of the comparison can be present as a difference of the values or as their ratio (parameter objvdr). Parameter timecomp is responsible for chosing the time values to compare. They can also be presented as differences or as ratios (parameter timedr).

Output table out_file contains 3 lines of header, beginning with "#", and one line per instance with the results of comparison.

2.5. param.conf

param.conf is a configuration database for all programs in the package. This file is read by default at each run of each program in this set. If you need to change the default, initialize the environment variable TORUNGAMS with the new file name. If you edit this file, do not change order of parameters, it may cause malfunction.

The parameters set in this file are as follows:

2.6. printnice.gms

This program is called by runall at step "b" to complete conversion of instances of type "2" to nice-looking format. For these instances, XPRESS-files contain data in the format different from one of all other instances. To make all inc-files consistent, this script reads gdx-file created by gams beforehand and dumps the elements of the matrix to the output file using GAMS facility "put".

Syntax: gams printnice --nicefile outfile.inc --gdxfile infile.gdx

2.7. Matrix statistics comparsion

The comparison is performed at step "k". As a prerequisite, RMIP problem must be solved for all translated and converted instances (which, if not done at steps "c" and "f", can be done separately at step "i"), and this program just extracts information from tracefiles. The following matrix parameters are extracted: number of equations, number of variables, number of discrete variables, and number of non-zeros. RMIP objective values are also extracted. All of them are output to the table mptab.extt together with the results of comparison in the last column: "ok" if values of all parameters coincide, empty space if not.

RMIP objective values are consistent for all instances. All instances show consistency by all 4 matrix parameters except for 3 models of datatype 8 (namely, h80x6320[bcd]). The reasons for that are purely technical: GAMS formulation of the linear programming problem for translated instances is slightly different from that in the XPRESS files. Number of equations and number of variables are consistent. Number of discrete variables and number of non-zoros are by 79 less for translated models. This is because in XPRESS models the constraint of zero flows from 79 demanding nodes to themselves is presented as a zero condition for corresponding binary forcing constraint variables (y=0), and GAMS models it is presented as condition for the upper limit (y=eps), which effectively excludes these variables from consideration.

2.8. Examples

It is assumed that test instances in XPRESS format (single-source and multi-source) and scripts (bchf-scripts.tgz) are unpacked into the same directory. It is necessary to "runall a" before any other processing steps.
  1. runall
    To perform all processing provided by the pipeline: create directory structure, translate instances, convert XPRESS-files, compare results of runs of converted and translated instances, compare matrix statistics, collect all instances in a specified directory.
  2. runall abi
    To translate all instances to GAMS format and copy them to the specified directory.
  3. togams 2s singlesource-web/beavma/beavma.mod
    To translate one particular model instance to GAMS format.
  4. rungams singlesource-web/berlin/berlin.inc singlesource-web/brasil/brasil.inc
    To run GAMS model with two specific test instances.

3. Running model instances

In this section we describe how to solve all model instances in bulk using different solvers and then compare the results of these runs. All programs described in this section are GAMS scripts, and therefore these runs can be performed on any platform supported by GAMS. It is assumed that test instances (single-source and multi-source) and GAMS command files (bchf-gms.tgz) are unpacked into the same directory.

The archive bchf-gms.tgz contains the following files:

  1. data.gms - a GAMS command file to run gams on a set of instances with a specified solver.
  2. schulz.gms - a GAMS command file to interrupt GAMS processes which do not terminate in the prespecified time limit.
  3. pprofile.gms - a GAMS command file to compare performance of different solvers based on trace-files provided by data.gms.
  4. bchfcnet.gms - a GAMS model file for use with data.gms.
  5. bchdicut.inc - a GAMS model file which implements dicut inequalities.
  6. bchfcheu.inc - a GAMS model file which implements heuristics.
You can find examples of usage below. (A general note to UNIX users: if you might want to "unset LANG" before running any of these programs, in order not to confuse awk with the format for floating point numbers.)

3.1. data.gms

The program data.gms is a script for GAMS to run test instances for a specified period of time. Either translated or converted instances can be run (however converted instances obviously cannot be run with BCHF). All instances are listed in the dataset "allinst", and table "mdata" defines starting points for turning on cuts and heuristics for hard instances (determined at step "h"). The loop over instances is performed over the set "m", which is the alias of the set "allinst" by default, but you can change it to a subset of "allinst". During the loop, the commands are appended to the file run.gms, and this file is launched by GAMS at the end of the script execution.

Syntax: gams data.gms [options]
The following options are possible:

The name of the output trace-file is the following: steprunopt.suffix.txt. E.g., for the run on translated instances with cuts and heuristics with solver CPLEX, provided corresponding input parameters, it could be bchrun1.cplex.cutsheur.txt. The following information is presented in the trace-file: instance name, number of variables, number of equations, number of non-zeros, model status, time consumed, objective value, objective value estimate.

3.2. schulz.gms

Sometimes experimental solvers do not terminate in the prespecified time limit or at all. Running batches of models with such a solver (e.g. for performance testing) requires frequent attention (to terminate the hanging process). This GAMS/awk program scans the list of processes and checks if the time (elapsed time, CPU time, etc.) exceedes the preset limit. If the time is exceeded, schulz sends a terminate signal to the process. If the process still doesn't terminate and remains in the list of processes, a more effective signal is sent.

Run this program in parallel with your computations to monitor running time of GAMS jobs.

Syntax: gams schulz [options]
The following options are possible:

3.3. pprofile.gms

This program compares performance of different solvers on a set of test instances. It extracts information from trace-files produced by data.gms and produces ASCII output tables which are intended for use as input for a grapher program. The following tables are produced:
  1. relative number of instances solved during specified time vs relative gap reached during this time (all instances are counted);
  2. relative number of instances solved to optimality by at least one of the solvers vs time consumed;
  3. relative number of instances solved during specified time vs relative gap reached during this time;
  4. relative number of instances solved during specified time vs best objective value reached during this time;
  5. relative number of instances solved during specified time vs best bound value reached during this time.
Tables III--V are built only from the instances not solved to optimality (see below), and "best" in their descriptions means "best among tested solvers". For each table, only those instances are counted which are present in all input trace-files.

All internal processing is performed by awk, which is called several times: for each output table, it is called to produce a list of instances of all participating solvers and to perform the comparison.

Syntax: gams pprofile.gms
This program does not have command line parameters. All parameters are specified within the body of the program. If you just follow the example given below, the default parameters will work. If you need to change them, below is the description of the parameters. Input trace-file lists are defined as GAMS sets, so it is easy to add other solvers to them if necessary.

There are also auxuliary parameters (defined as GAMS parameters) to set the accuracy of comparison of two floating point numbers, the absolute possible upper bound for the objective value (used in search for minimum), the names of the temporary files for awk-scripts, and the field numbers of each investigated parameter (gap, objective value, etc.) in the input trace-files.

3.3. Examples

Here is a list of commands which you need to perform in order to reproduce graphs presented in the next section:

Create a separate directory for each run (different solvers, with/without cuts/heuristics)
Unpack the archives bchf-gms.tgz and bchf-inst.tgz into each directory
gams schulz --watch gmscp_ux.out --time etime --sleep 60 --resseq 2:3:9 --sigseq 1800:1850:1900
In corresponding directories:
gams data --solver cplex --optfile 0 --cutsoff 1 --heuroff 1 --suffix cplex
gams data --solver cplex --optfile 1 --cutsoff 0 --heuroff 1 --suffix cplex.cuts
gams data --solver cplex --optfile 1 --cutsoff 0 --heuroff 0 --suffix cplex.cutsheur
gams data --solver xpress --optfile 0 --cutsoff 1 --heuroff 1 --suffix xpress
gams data --solver xa --optfile 0 --cutsoff 1 --heuroff 1 --suffix xa
Copy all files bchrun*txt to a separate directory and run there
gams pprofile

4. Results of our test runs

We performed our computations on a computer with two Athlon MP 2800+ CPUs and 2 Gb of RAM. 1800 seconds were allotted for each of 83 instances. Performace of solvers CPLEX, XPRESS and XA was compared to the performace of CPLEX with cuts enabled and CPLEX with both cuts and heuristics enabled, illustrated on the graphs below (source files for these graphs in Grace format can be found in the archive bchf-agr.tgz).

All instances, all solvers vs gap Relative number of instances solved durng 1800 s vs relative gap reached during this time (all instances are counted).

Solved instances vs time Relative number of instances solved to optimality by XPRESS and/or CPLEX vs time consumed.

Unsolved instances vs gap Relative number of instances solved during 1800 s vs relative gap reached during this time ("super-solver" is a synthetic solver, for each instance it is a solver providing best value of the gap). Only instances not solved by both CPLEX and XPRESS are counted.

Unsolved instances vs objective Relative number of instances solved during 1800 s vs best objective value reached during this time. Only instances not solved by both CPLEX and XPRESS are counted.

Unsolved instances vs best bound Relative number of instances solved during 1800 s vs best bound value reached during this time. Only instances not solved by both CPLEX and XPRESS are counted.