Model Solution#

int GRBoptimize(GRBmodel *model)#

Optimize a model. The algorithm used for the optimization depends on the model type (simplex or barrier for a continuous model; branch-and-cut for a MIP model). Upon successful completion, this method will populate the solution related attributes of the model. See the Attributes section for more information on attributes.

Please consult this section for a discussion of some of the practical issues associated with solving a precisely defined mathematical model using finite-precision floating-point arithmetic.

Note that this routine will process all pending model modifications.

Return value:

A non-zero return value indicates that a problem occurred while optimizing the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The model to optimize. Note that this routine only reports whether the optimization ran into an error. Query the Status attribute to determine the result of the optimization (see the Attributes section for more information on querying attributes).

Example:
error = GRBoptimize(model);
int GRBoptimizeasync(GRBmodel *model)#

Optimize a model asynchronously. This routine returns immediately. Your program can perform other computations while optimization proceeds in the background. To check the state of the asynchronous optimization, query the Status attribute for the model. A value of IN_PROGRESS indicates that the optimization has not yet completed. When you are done with your foreground tasks, you must call GRBsync to sync your foreground program with the asynchronous optimization task.

Note that the set of Gurobi calls that you are allowed to make while optimization is running in the background is severely limited. Specifically, you can only perform attribute queries, and only for a few attributes (listed below). Any other calls on the running model, or on any other models that were built within the same Gurobi environment, will fail with error code OPTIMIZATION_IN_PROGRESS.

Note that there are no such restrictions on models built in other environments. Thus, for example, you could create multiple environments, and then have a single foreground program launch multiple simultaneous asynchronous optimizations, each in its own environment.

As already noted, you are allowed to query the value of the Status attribute while an asynchronous optimization is in progress. The other attributes that can be queried are: ObjVal, ObjBound, IterCount, NodeCount, and BarIterCount. In each case, the returned value reflects progress in the optimization to that point. Any attempt to query the value of an attribute not on this list will return an OPTIMIZATION_IN_PROGRESS error.

Return value:

A non-zero return value indicates that a problem occurred while optimizing the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The model to optimize. Note that this routine only reports whether launching the asynchronous job ran into an error. Query the Status attribute to determine the result of the optimization (see the Attributes section for more information on querying attributes). The return value of GRBsync indicates whether the background optimization ran into an error.

Example:
error = GRBoptimizeasync(model);

/* ... perform other compute-intensive tasks... */

error = GRBsync(model);
int GRBcomputeIIS(GRBmodel *model)#

Compute an Irreducible Inconsistent Subsystem (IIS).

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.

This routine populates the IISConstr, IISGenConstr, IISQConstr, IISSOS, IISLB, and IISUB attributes. You can also obtain information about the results of the IIS computation by writing a .ilp format file (see GRBwrite). This file contains only the IIS from the original model.

Use the IISMethod parameter to adjust the behavior of the IIS algorithm.

Note that this routine can be used to compute IISs for both continuous and MIP models.

Return value:

A non-zero return value indicates that a problem occurred while computing the IIS. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The infeasible model. This routine will return an error if the input model is feasible.

Important

This routine only reports whether the computation ran into an error. Query the IISConstr, IISGenConstr, IISQConstr, IISSOS, IISLB, or IISUB attributes to determine the result of the computation (see the Attributes section for more information on querying attributes).

Example:
error = GRBcomputeIIS(model);
int GRBfeasrelax(GRBmodel *model, int relaxobjtype, int minrelax, double *lbpen, double *ubpen, double *rhspen, double *feasobjP)#

Modifies the input model to create a feasibility relaxation. Note that you need to call GRBoptimize on the result to compute the actual relaxed solution.

The feasibility relaxation is a model that, when solved, minimizes the amount by which the solution violates the bounds and linear constraints of the original model. This routine provides a number of options for specifying the relaxation.

If you specify relaxobjtype=0, the objective of the feasibility relaxation is to minimize the sum of the weighted magnitudes of the bound and constraint violations. The lbpen, ubpen, and rhspen arguments specify the cost per unit violation in the lower bounds, upper bounds, and linear constraints, respectively.

If you specify relaxobjtype=1, the objective of the feasibility relaxation is to minimize the weighted sum of the squares of the bound and constraint violations. The lbpen, ubpen, and rhspen arguments specify the coefficients on the squares of the lower bound, upper bound, and linear constraint violations, respectively.

If you specify relaxobjtype=2, the objective of the feasibility relaxation is to minimize the weighted count of bound and constraint violations. The lbpen, ubpen, and rhspen arguments specify the cost of violating a lower bound, upper bound, and linear constraint, respectively.

To give an example, a violation of 2.0 on constraint i would contribute 2*rhspen[i] to the feasibility relaxation objective for relaxobjtype=0, it would contribute 2*2*rhspen[i] for relaxobjtype=1, and it would contribute rhspen[i] for relaxobjtype=2.

The minrelax argument is a boolean that controls the type of feasibility relaxation that is created. If minrelax=0, optimizing the returned model gives a solution that minimizes the cost of the violation. If minrelax=1, optimizing the returned model finds a solution that minimizes the original objective, but only from among those solutions that minimize the cost of the violation. Note that GRBfeasrelax must solve an optimization problem to find the minimum possible relaxation for minrelax=1, which can be quite expensive.

In all cases, you can specify a penalty of GRB_INFINITY to indicate that a specific bound or linear constraint may not be violated.

For an example of how this routine transforms a model, and more details about the variables and constraints created, please see this section.

Note that this is a destructive routine: it modifies the model passed to it. If you don’t want to modify your original model, use GRBcopymodel to create a copy before calling this routine.

Return value:

A non-zero return value indicates that a problem occurred while computing the feasibility relaxation. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The original (infeasible) model. The model is modified by this routine.

  • relaxobjtype – The cost function used when finding the minimum cost relaxation.

  • minrelax – The type of feasibility relaxation to perform.

  • lbpen – The penalty associated with violating a lower bound. Can be NULL, in which case no lower bound violations are allowed. If not NULL, this should be an array with as many values as variables that currently exist in the model. Note that artificial variables may have been created automatically by Gurobi for range constraints.

  • ubpen – The penalty associated with violating an upper bound. Can be NULL, in which case no upper bound violations are allowed. If not NULL, this should be an array with as many values as variables that currently exist in the model. Note that artificial variables may have been created automatically by Gurobi for range constraints.

  • rhspen – The penalty associated with violating a linear constraint. Can be NULL, in which case no constraint violations are allowed. If not NULL, this should be an array with as many values as constraints that currently exist in the model.

  • feasobjP – When minrelax=1, this returns the objective value for the minimum cost relaxation.

Example:
double penalties[];
error = GRBfeasrelax(model, 0, 0, NULL, NULL, penalties, NULL);
error = GRBoptimize(model);
int GRBfixmodel(GRBmodel *model, GRBmodel **fixedP)#

Create the fixed model associated with a MIP model. The MIP model must have a solution loaded (e.g., after a call to GRBoptimize). In the fixed model, each integer variable is fixed to the value that variable takes in the MIP solution. In addition, continuous variables may be fixed to satisfy SOS or general constraints. The result is a model without any integrality constraints, SOS constraints, or general constraints.

Note that, while the fixed problem is always a continuous model, it may contain a non-convex quadratic objective or non-convex quadratic constraints. As a result, it may still be solved using the MIP algorithm.

Return value:

A non-zero return value indicates that a problem occurred while creating the fixed model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The MIP model (with a solution loaded).

  • fixedP – The computed fixed model.

Example:
GRBmodel *fixed;
error = GRBfixmodel(model, &fixed);
int GRBreset(GRBmodel *model, int clearall)#

Reset the model to an unsolved state, discarding any previously computed solution information.

Return value:

A non-zero return value indicates that a problem occurred while resetting the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The model to reset.

  • clearall – A value of 1 discards additional information that affects the solution process but not the actual model (currently MIP starts, variable hints, branching priorities, lazy flags, and partition information). Pass 0 to just discard the solution.

Example:
error = GRBreset(model, 0);
int GRBsync(GRBmodel *model)#

Wait for a previous asynchronous optimization call to complete.

Calling GRBoptimizeasync returns control to the calling routine immediately. The caller can perform other computations while optimization proceeds, and can check on the progress of the optimization by querying various model attributes. The GRBsync call forces the calling program to wait until the asynchronous optimization completes. You must call GRBsync before the corresponding model is freed.

The GRBsync call returns a non-zero error code if the optimization itself ran into any problems. In other words, error codes returned by this method are those that GRBoptimize itself would have returned, had the original method not been asynchronous.

Note that you need to call GRBsync even if you know that the asynchronous optimization has already completed.

Return value:

A non-zero return value indicates that a problem occurred while solving the model. Refer to the Error Codes table for a list of possible return values. Details on the error can be obtained by calling GRBgeterrormsg.

Arguments:

  • model – The model that is currently being solved.

Example:
error = GRBoptimizeasync(model);

/* ... perform other compute-intensive tasks... */

error = GRBsync(model);