Gurobi

Introduction

Gurobi Optimizer has been designed to be a fast and powerful solver for your LP, QP, QCP, and MIP problems. More information can be found on the Gurobi webpage. Read the Quickstart Guide for examples on how to use gurobi.

Please note that Gurobi Optimizer is commercial software. The academic license available at the University Oldenburg can only be used for research and teaching puporses. If you have used Gurobi in your research you can acknowledge this by citing

@misc{gurobi,
  author = "Gurobi Optimization, Inc.",
  title = "Gurobi Optimizer Reference Manual",
  year = 2015,
  url = "http://www.gurobi.com"
}

Using Gurobi Optimizer on the Cluster

In order to use Gurobi Optimizer you need to load the module with the command

module load gurobi/6.5.1

This sets up the environment to run e.g. the command-line tool. To get some help type

gurobi_cl --help

The general format for the command-line tool is

gurobi_cl [--command]* [param=value]* filename

where filename contains a model for optimization. Using one of the examples described in the http://www.gurobi.com/documentation/ Quickstart Guide], a working command could look like this:

gurobi_cl Threads=1 $GUROBI_HOME/examples/data/coins.lp

Here, $GUROBI_HOME is set in the environment, coins.lp is an example model. The option Threads=1 set the parameter Threads to 1. This is an important option when you run Gurobi on the cluster: if not used Gurobi may use all available cores on a compute node which could interfere with other jobs (and therefore should be avoided!). The command above rund very quickly and produces a few lines of output. In addition, a file gurobi.log is created (or appended to if it already exists).

Sample Job Script

In most cases you need to run an optimization that needs longer run time. In that case you should prepare and submit a job script as explained in the section about the SGE Job Management (Queueing) System. A job script could look like this:

#!/bin/bash

### the following lines are used by SGE to determine your job requirements
### you may want to modify the requested resources, e.g. h_vmem or h_rt,
### if you need more memory or run time (respectively)
### PE SMP is used, comment out if you only need 1 computing core
#$ -S /bin/bash
#$ -cwd
#$ -pe smp 8            # number of slots requested (maximum is 12 for PE SMP)
#$ -l h_rt=1:00:0       # requested time hh:mm:ss
#$ -l h_vmem=1500M      # requested memory per slot if PE SMP is used
#$ -l h_fsize=100G
#$ -N gurobi
#$ -j n

### maybe useful to receive emails when a job begins (b) and has finished (e)
### (to activate change email address and remove extra # in the next 2 lines)
##$ -m be
##$ -M your.name@uni-oldenburg.de

### here the actual job script begins
### you may want to modify this part according to your needs
echo Job started on `date`   # put a time stamp in log file

# load module gurobi
module load gurobi

# settings (here you need to make your own modifications)
INPUTFILE=$GUROBI_HOME/examples/data/glass4.mps     # full path and name of input file
RESULTFILE=`basename $INPUTFILE | sed -e "s/\..*$/.sol/"` # filename for result file

# create a directory for this run
mkdir gurobi_${JOB_ID}
cd gurobi_${JOB_ID}

# run gurobi (command-line tool) with some options
# see documentation for more information about options
# do not change or remove the Threads=$NSLOTS
gurobi_cl MIPFocus=1 Threads=$NSLOTS ResultFile=$RESULTFILE $INPUTFILE

echo Job finished on `date`   # put a time stamp in log file
exit

Here the lines beginning with #$ describe the requested resources for the job and other settings. You may need to modify these according to your needs. Note that the SMP parallel environment (#$ -pe smp <N>) is requested because Gurobi can make use of multi-core architectures. The information about the number of available slots is passed in the Threads= option using the variable $NSLOTS. If you want to change the number of slots you only need to modify the value of <N>. Note that not all parts of Gurobi can run in parallel and increasing the number of cores does not alway improve the performance. Please test this before wasting compute resources (the example glass4.mps runs in 500s on 8 cores and in 235s on 16 cores, which is very good). If you remove or comment out the request for PE smp NSLOTS will be set to 1 (i.e. you don't need to modify the Threads option).

The job script is creating a new directory at the location where the job was submitted and all output from Gurobi will be written to that directory. The output from the SGE will be found where the job script is. The script is somewhat generic, you can change the location and name of the input file, the result file name will be created automatically.

If you need to make a large number of runs with similar input files/parameters consider using a job array.