Hide navigation sidebar
Hide table of contents sidebar
Back to top
Toggle table of contents sidebar

# 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. The algorithm will terminate early if it reaches any of the limits set by termination parameters.

  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 GRB_INPROGRESS 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 GRB_ERROR_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, BarIterCount, NLBarIterCount, and NLBarIterCount. 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 fail with error code GRB_ERROR_OPTIMIZATION_IN_PROGRESS.

  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 GRBpresolvemodel(GRBmodel *model, GRBmodel **presolvedP)

  Perform presolve on a model.

  Please note that the presolved model computed by this function may be different from the presolved model computed when optimizing the model.

  Return value:

    A non-zero return value indicates that a problem occurred while presolving 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 be presolved.

    - presolveP – The location in which the pointer to the presolved model should be placed.

  Example:

        error = GRBpresolvemodel(model, &presolvedP);

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.

  Termination parameters such as TimeLimit, WorkLimit, MemLimit, and SoftMemLimit are considered when computing an IIS. If an IIS computation is interrupted before completion or stops due to a termination parameter, Gurobi will return the smallest infeasible subsystem found to that point. The model attribute IISMinimal can be used to check whether the computed IIS is minimal.

  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 GRBconverttofixed(GRBmodel *model)

  Turn the MIP model into a continuous one, in place. A solution (e.g. obtained through a call to `GRBoptimize`) or a MIP start must be available in the MIP model. If no solution is available, the MIP start specified with StartNumber is used.

  In the model, each integer variable is fixed to the value that variable takes in the MIP solution or MIP start. In addition, continuous variables may be fixed to satisfy SOS or general constraints. The result is that the model has neither integrality constraints, SOS constraints, nor general constraints any more.

  Note

  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.

  Note

  An error is raised if the converted model contains more than one objective or scenario, or if the model contains concurrent environments or tune environments.

  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) to fix.

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. A solution (e.g. obtained through a call to `GRBoptimize`) or a MIP start must be available in the MIP model. If no solution is available, the MIP start specified with StartNumber is used.

  In the model, each integer variable is fixed to the value that variable takes in the MIP solution or MIP start. In addition, continuous variables may be fixed to satisfy SOS or general constraints. The result is that the model has neither integrality constraints, SOS constraints, nor general constraints any more.

  Note

  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.

  Note

  On a multi-objective model, all but the first objectives are ignored. All scenarios are ignored as well, if any.

  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);

Help and Feedback

Press `/` or click to search this documentation | Gurobi website | Gurobi community forum
Go to other Gurobi documentation | Gurobi download | Contact support