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), or .attr
(a collection of attributes). For example, the following command:
gurobi_cl InputFile=model.bas model.mps
would start the optimization of the continuous model stored in file
model.mps
using the basis provided in file model.bas
.
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.
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.