# C API Overview

##

C API Overview

This section documents the Gurobi C interface. This manual begins with a quick overview of the functions in the interface, and continues with detailed descriptions of all of the available interface routines.

If you are new to the Gurobi Optimizer, we suggest that you start with the Quick Start Guide or the Example Tour. These documents provide concrete examples of how to use the routines described here.

Environments

The first step in using the Gurobi C optimizer is to create an environment, using the GRBloadenv call. The environment acts as a container for all data associated with a set of optimization runs. You will generally only need one environment in your program, even if you wish to work with multiple optimization models. Once you are done with an environment, you should call GRBfreeenv to release the associated resources.

Models

You can create one or more optimization models within an environment. A model consists of a set of variables, a linear or quadratic objective function on those variables, and a set of constraints. Each variable has an associated lower bound, upper bound, type (continuous, binary, integer, semi-continuous, or semi-integer), and linear objective coefficient. Each linear constraint has an associated sense (less-than-or-equal, greater-than-or-equal, or equal), and right-hand side value.

An optimization model may be specified all at once, through the GRBloadmodel routine, or built incrementally, by first calling GRBnewmodel and then calling GRBaddvars to add variables and GRBaddconstr or GRBaddqconstr to add constraints. Models are dynamic entities; you can always add or delete variables or constraints.

Specific variables and constraints are referred to throughout the Gurobi C interface using their indices. Variable/constraint indices are assigned as variables/constraints are added to the model, in a contiguous fashion. In adherence to C language conventions, indices all start at 0.

We often refer to the *class* of an optimization model. A model
with a linear objective function, linear constraints, and continuous
variables is a *Linear Program (LP)*. If the objective is
quadratic, the model is a *Quadratic Program (QP)*. If any of the
constraints are quadratic, the model is a
*Quadratically-Constrained Program (QCP)*.
We'll sometimes also discuss a special case of QCP,
the
*Second-Order Cone Program (SOCP)*. If the model contains any
integer variables, semi-continuous variables, semi-integer variables,
or Special Ordered Set (SOS) constraints, the model is a
*Mixed Integer Program (MIP)*. We'll also sometimes discuss
special cases of MIP,
including
*Mixed Integer Linear Programs (MILP)*,
*Mixed Integer Quadratic Programs (MIQP)*,
*Mixed Integer Quadratically-Constrained Programs (MIQCP)*,
and
*Mixed Integer Second-Order Cone Programs (MISOCP)*.
The Gurobi Optimizer handles all of these model classes.

Solving a Model

Once you have built a model, you can call
GRBoptimize to compute a solution.
By default, `GRBoptimize()`

will use the
concurrent optimizer
to solve LP models, the barrier algorithm to solve QP and QCP models,
and the branch-and-cut algorithm to solve
mixed integer models. The solution is stored as a set of
*attributes* of the model. The C interface contains an extensive
set of routines for querying these attributes.

The Gurobi algorithms keep careful track of the state of the model,
so calls to `GRBoptimize()`

will only perform further
optimization if relevant data has changed since the model was last
optimized. If you would like to discard previously computed solution
information and restart the optimization from scratch without changing
the model, you can call
GRBresetmodel.

After a MIP model has been solved, you can call
GRBfixedmodel to compute the
associated *fixed* model. This model is identical to the input
model, except that all integer variables are fixed to their values in
the MIP solution. In some applications, it is useful to compute
information on this continuous version of the MIP model (e.g., dual
variables, sensitivity information, etc.).

Infeasible Models

You have a few options if a model is found to be infeasible. You can try to diagnose the cause of the infeasibility, attempt to repair the infeasibility, or both. To obtain information that can be useful for diagnosing the cause of an infeasibility, call GRBcomputeIIS to compute an Irreducible Inconsistent Subsystem (IIS). This routine can be used for both continuous and MIP models, but you should be aware that the MIP version can be quite expensive. This routine populates a set of IIS attributes.

To attempt to repair an infeasibility, call GRBfeasrelax to compute a feasibility relaxation for the model. This relaxation allows you to find a solution that minimizes the magnitude of the constraint violation.

Querying and Modifying Attributes

Most of the information associated with a Gurobi model is stored in a
set of attributes. Some attributes are associated with the variables
of the model, some with the constraints of the model, and some with
the model itself. To give a simple example, solving an optimization
model causes the `X`

variable attribute to be populated.
Attributes such as `X`

that are computed by the Gurobi optimizer
cannot be modified directly by the user, while others, such as the
variable lower bound array (the `LB`

attribute) can.

The Gurobi C interface contains an extensive set of routines for
querying or modifying attribute values. The exact routine to use for
a particular attribute depends on the type of the attribute. As
mentioned earlier, attributes can be either variable attributes,
constraint attributes, or model attributes. Variable and constraint
attributes are arrays, and use a set of array attribute routines.
Model attributes are scalars, and use a set of scalar routines.
Attribute values can additionally be of type *char*,
*int*, *double*, or *string* (really *char **).

Scalar model attributes are accessed through a set of
`GRBget*attr()`

routines (e.g.,
GRBgetintattr). In addition,
those model attributes that can be set directly by the user (e.g., the
objective sense) may be modified through the `GRBset*attr()`

routines (e.g.,
GRBsetdblattr).

Array attributes are accessed through three sets of routines. The
first set, the `GRBget*attrarray()`

routines (e.g.,
GRBgetcharattrarray)
return a contiguous sub-array of the attribute array, specified using
the index of the first member and the length of the desired sub-array.
The second set, the `GRBget*attrelement()`

routines (e.g.,
GRBgetcharattrelement)
return a single entry from the attribute array. Finally, the
`GRBget*attrlist()`

routines (e.g.,
GRBgetdblattrlist) retrieve
attribute values for a list of indices.

Array attributes that can be set by the user are modified through the
`GRBset*attrarray()`

, `GRBset*attrelement()`

, and
`GRBset*attrlist()`

routines.

The full list of Gurobi attributes can be found in the Attributes section.

Additional Model Modification Information

Most modifications to an existing model are done through the attribute interface (e.g., changes to variable bounds, constraint right-hand sides, etc.). The main exceptions are modifications to the constraint matrix and to the quadratic portion of the objective function.

The constraint matrix can be modified in a few ways. The first is to call GRBchgcoeffs to change individual matrix coefficients. This routine can be used to modify the value of an existing non-zero, to set an existing non-zero to zero, or to create a new non-zero. The constraint matrix is also modified when you remove constraints (through GRBdelconstrs) or variables (through GRBdelvars). The non-zero values associated with the deleted constraints or variables are removed along with the constraints or variables themselves.

Quadratic objective terms are added to the objective function using the
GRBaddqpterms routine. You can
add a list of quadratic terms in one call, or you can add terms
incrementally through multiple calls. The
GRBdelq routine allows you to delete
all quadratic terms from the model. Note that quadratic models will
typically have both quadratic and linear terms. Linear terms are
entered and modified through the `Obj`

attribute, in the same
way that they are handled for models with purely linear objective
functions.

If your variables have piecewise-linear objectives, you can specify
them using the GRBsetpwlobj
routine. Call this routine once for each relevant variable. The
Gurobi simplex solver includes algorithmic support for convex
piecewise-linear objective functions, so for continuous models you
should see a substantial performance benefit from using this feature.
To clear a previously specified piecewise-linear objective function,
simply set the `Obj`

attribute on the corresponding variable to
0.

Lazy Updates

One very important item to note about model modifications in the
Gurobi optimizer is that they are performed in a *lazy* fashion,
meaning that they don't actually affect the model until the next call
to GRBoptimize or
GRBupdatemodel. This approach
provides the advantage that the model remains unchanged while you are
in the process of making multiple modifications. The downside, of
course, is that you have to remember to call `GRBupdatemodel()`

in order to see the effect of your changes.

If you forget to call update, your program won't crash. The most
common symptom of a missing update is an `INDEX_OUT_OF_RANGE`
error, which indicates that the object you are trying to reference
isn't in the model yet.

If you find the need to call GRBupdatemodel inconvenient, you can adjust the behavior of lazy updates with the UpdateMode parameter. By setting this parameter to 1, you can use newly added variables and constraints immediately for building or modifying the model. This setting does have a few downsides, though. It causes Gurobi to use a small amount of additional internal storage, and it introduces a small performance overhead. In addition, this setting may cause Gurobi to make less aggressive use of warm-start information when you modify a model and resolve it using simplex.

Managing Parameters

The Gurobi optimizer provides a set of parameters to allow you to
control many of the details of the optimization process. Factors like
feasibility and optimality tolerances, choices of algorithms,
strategies for exploring the MIP search tree, etc., can be controlled
by modifying Gurobi parameters before beginning the optimization.
Parameters are set using the `GRBset*param()`

routines (e.g.,
GRBsetintparam). Current
values can be retrieved with the `GRBget*param()`

routines
(e.g., GRBgetdblparam).
Parameters can be of type *int*, *double*, or *char
** (string). You can also read a set of parameter settings from a
file using GRBreadparams, or
write the set of changed parameters using
GRBwriteparams.

We also include an automated parameter tuning tool that explores many different sets of parameter changes in order to find a set that improves performance. You can call GRBtunemodel to invoke the tuning tool on a model. Refer to the parameter tuning tool section for more information.

One thing we should note is that each model gets its own copy of the environment when it is created. Parameter changes to the original environment therefore have no effect on existing models. Use GRBgetenv to retrieve the environment associated with a particular model if you want to change a parameter for that model.

Monitoring Progress - Logging and Callbacks

Progress of the optimization can be monitored through Gurobi logging. By default, Gurobi will send output to the screen. A few simple controls are available for modifying the default logging behavior. If you would like to direct output to a file as well as to the screen, specify the log file name in GRBloadenv when you create your environment. You can modify the LogFile parameter if you wish to redirect the log to a different file after creating the environment. The frequency of logging output can be controlled with the DisplayInterval parameter, and logging can be turned off entirely with the OutputFlag parameter. A detailed description of the Gurobi log file can be found in the Logging section.

More detailed progress monitoring can be done through the Gurobi callback function. The GRBsetcallbackfunc routine allows you to install a function that the Gurobi optimizer will call regularly during the optimization process. You can call GRBcbget from within the callback to obtain additional information about the state of the optimization.

Modifying Solver Behavior - Callbacks

Callbacks can also be used to modify the behavior of the Gurobi
optimizer. If you call routine
GRBterminate from within a
callback, for example, the optimizer will terminate at the earliest
convenient point. Routine
GRBcbsolution allows you to
inject a feasible solution (or partial solution) during the solution
of a MIP model. Routines GRBcbcut
and GRBcblazy
allow you to add *cutting planes* and *lazy constraints*
during a MIP optimization, respectively.

Error Handling

Most of the Gurobi C library routines return an integer error code. A zero return value indicates that the routine completed successfully, while a non-zero value indicates that an error occurred. The list of possible error return codes can be found in the Error Codes section.

When an error occurs, additional information on the error can be obtained by calling GRBgeterrormsg.