Gurobi Command-Line Tool#

The Gurobi command-line tool allows you to perform simple commands without the overhead or complexity of an interactive interface. While the most basic usage of the command-line tool is quite straightforward, the tool has a number of uses that are perhaps less obvious. This section talks about its full capabilities.

To use this tool, you’ll need to type commands into a command-line interface. Linux and Mac users can use a Terminal window. Windows users will need to open a Command Prompt (also known as a Console window or a cmd window). To launch one, hold down the Start and R keys simultaneously, and then type cmd into the Run box that appears.

The command to solve a model using the command-line tool is:

gurobi_cl [parameter=value]* modelfile

The Gurobi log file is printed to the screen as the model solves, and the command terminates when the solve is complete. Parameters are chosen from among the Gurobi parameters. The final argument is the name of a file that contains an optimization model, stored in MPS or LP format. You can learn more about using the command-line tool to solve models in this section.

The command-line tool can also be used to replay recordings of API calls. The command for this usage is:

gurobi_cl recordingfile

A recording file is a binary file generated by Gurobi with a .grbr extension. You can learn more about using the command-line tool to replay recordings in this section.

The command-line tool can also be used to check on the status of a Gurobi token server. The command is:

gurobi_cl --tokens

This command will show you whether the token server is currently serving tokens, and which users and machines are currently using tokens.

You can also type:

gurobi_cl --help

to get help on the use of the tool, or:

gurobi_cl --version

to get version information, or:

gurobi_cl --license

to get the location of the current Gurobi license file.

Solving a Model#

The command-line tool provides an easy way to solve a model stored in a file. The model can be stored in several different formats, including MPS, REW, LP, and RLP, and the file can optionally be compressed using gzip, bzip2, or 7z. See the File Format discussion for more information on accepted formats.

The most basic command-line command is the following:

gurobi_cl model.mps

This will read the model from the indicated file, optimize it, and display the Gurobi log file as the solve proceeds.

You can optionally include an arbitrary number of parameter=value commands before the name of the file. For example:

gurobi_cl Method=2 TimeLimit=100 model.mps

The full set of Gurobi parameters is described in the Parameters section.

Gurobi Compute Server users can add the --server= switch to specify a server. For example, the command:

gurobi_cl --server=server1 Method=2 TimeLimit=100 model.mps

would solve the model stored in file model.mps on machine server1, assuming it is running Gurobi Compute Server. If the Compute Server has an access password, use the --password= switch to specify it.

Gurobi Instant Cloud users can add the --accessid=, --secretkey=, and --pool= switches to run a model on a cloud instance. For example, the command:

gurobi_cl --accessid=0f5e0ace-f929-a919-82d5-02272b3b0e19 \
          --secretkey=8EDZOIf7T9avp0ZHef9Tsw --pool=mypool model.mps

would solve the model stored in file model.mps on cloud pool mypool using the provided access ID and secret key. If the pool isn’t currently active, it will launch it first.

Writing Result Files#

While it is often useful to simply solve a model and display the log, it is also common to want to review the resulting solution. You can use the ResultFile parameter to write the solution to a file:

gurobi_cl ResultFile=model.sol model.mps

The file name suffix determines the type of file written. Useful file formats for solution information are .sol (for solution vectors) and .bas (for simplex basis information). Again, you should consult the section on File Formats for a list of the supported formats

If you have an infeasible model, you may want to examine a corresponding Irreducible Inconsistent Subsystem (IIS) to identify the cause of the infeasibility. You can ask the command-line tool to write a .ilp format file. It will attempt to solve the model, and if the model is found to be infeasible, it will automatically compute an IIS and write it to the requested file name.

An IIS is a subset of the constraints and variable bounds with the following properties:

  • It is still infeasible, and

  • If a single constraint or bound is removed, the subsystem becomes feasible.

Note that an infeasible model may have multiple IISs. The one returned by Gurobi is not necessarily the smallest one; there may exist others with fewer constraints or bounds.

IIS results are returned in a number of attributes: IISConstr, IISLB, IISUB, IISSOS, IISQConstr, and IISGenConstr. Each indicates whether the corresponding model element is a member of the computed IIS.

Note that for models with general function constraints, piecewise-linear approximation of the constraints may cause unreliable IIS results.

The IIS log provides information about the progress of the algorithm, including a guess at the eventual IIS size.

If an IIS computation is interrupted before completion, Gurobi will return the smallest infeasible subsystem found to that point.

The IISConstrForce, IISLBForce, IISUBForce, IISSOSForce, IISQConstrForce, and IISGenConstrForce attributes allow you mark model elements to either include or exclude from the computed IIS. Setting the attribute to 1 forces the corresponding element into the IIS, setting it to 0 forces it out of the IIS, and setting it to -1 allows the algorithm to decide.

To give an example of when these attributes might be useful, consider the case where an initial model is known to be feasible, but it becomes infeasible after adding constraints or tightening bounds. If you are only interested in knowing which of the changes caused the infeasibility, you can force the unmodified bounds and constraints into the IIS. That allows the IIS algorithm to focus exclusively on the new constraints, which will often be substantially faster.

Note that setting any of the Force attributes to 0 may make the resulting subsystem feasible, which would then make it impossible to construct an IIS. Trying anyway will result in a IIS_NOT_INFEASIBLE error. Similarly, setting this attribute to 1 may result in an IIS that is not irreducible. More precisely, the system would only be irreducible with respect to the model elements that have force values of -1 or 0.

Another use of ResultFile is to translate between file formats. For example, if you want to translate a model from MPS format to LP format, you could issue the following command:

gurobi_cl TimeLimit=0 ResultFile=model.lp model.mps

Gurobi can write compressed files directly, so this command would also work (assuming that 7zip is installed on your machine):

gurobi_cl TimeLimit=0 ResultFile=model.lp.7z model.mps

The ResultFile parameter works differently from other parameters in the command-line interface. While a parameter normally takes a single value, you can actually specify multiple result files. For example, the following command:

gurobi_cl ResultFile=model.sol ResultFile=model.bas model.mps

will write two files.

Reading Input Files#

You can use the InputFile parameter to read input files during the optimization. The most common input formats are .bas (a simplex basis), .mst (a MIP start), .sol (also a MIP start), .hnt (MIP hints), .ord (a MIP priority order), .attr (a collection of attributes), or .prm (a collection of parameters). For example, the following command:

gurobi_cl InputFile=model.bas InputFile=params.prm model.mps

would start the optimization of the continuous model stored in file model.mps using the basis provided in file model.bas and the parameters specified in params.prm.

Except for .prm files, reading input files is equivalent to setting the values of Gurobi attributes. A .bas file populates the VBasis and CBasis attributes, while a .ord file populates the BranchPriority attribute. A .mst or .sol file populates the Start attribute. A .hnt file populates the VarHintVal and VarHintPri attributes. A .attr file can hold a collection of these attributes.

In the case of .prm files, reading the file is equivalent to setting the parameters on the command-line directly using the parameter=value syntax.

Again, you should consult the File Formats section for more information on supported file formats

Replaying Recording Files#

If you’ve generated a recording of the Gurobi API calls made by your program, you may use the command-line tool to replay this recording.

Recordings are stored in files with .grbr extensions. To replay a recording from a file named recording000.grbr issue the following command:

gurobi_cl recording000.grbr

You should adjust the file name to match the recording you wish to replay.

You will know you have succeeded in replaying a recording, if you see lines similar to the following at the beginning of the command-line tool’s output:

*Replay* Replay of file 'recording000.grbr'
*Replay* Recording captured Tue Sep 13 19:28:48 2023
*Replay* Recording captured with Gurobi version 10.0.3 (linux64)

For information about recording API calls and replaying them, see the Recording API Calls chapter.