Gurobi Optimization, www.gurobi.com

Introduction

The Gurobi suite of optimization products include state-of-the-art simplex and parallel barrier solvers for linear programming (LP) and quadratic programming (QP), parallel barrier solver for quadratically constrained programming (QCP), as well as parallel mixed-integer linear programming (MILP), mixed-integer quadratic programming (MIQP), mixed-integer quadratically constrained programming (MIQCP) and (mixed-integer) nonlinear programming (NLP) solvers.

The Gurobi MIP solver includes shared memory parallelism, capable of simultaneously exploiting any number of processors and cores per processor. The implementation is deterministic: two separate runs on the same model will produce identical solution paths.

While numerous solving options are available, Gurobi automatically calculates and sets most options at the best values for specific problems. All Gurobi options available through GAMS/Gurobi are summarized at the end of this chapter.

We offer a GAMS/Gurobi-Link license that works in combination with a Gurobi callable library license from Gurobi Optimization Inc.

Attention

The free bare-bone link mode (previously GAMS/OSIGUROBI) that allowed to solve LP and MIP when the user had a separate GUROBI license has been removed. If you relied on using this bare-bone link option, then do not hesitate to contact sales@gams.com to arrange for a GAMS/Gurobi-Link license.

How to Run a Model with Gurobi

The following statement can be used inside your GAMS program to specify using Gurobi

   Option LP = Gurobi;  { or MIP or RMIP or QCP or MIQCP or RMIQCP }

The above statement should appear before the solve statement. If Gurobi was specified as the default solver during GAMS installation, the above statement is not necessary.

Overview of GAMS/Gurobi

Linear, Quadratic and Quadratic Constrained Programming

Gurobi can solve LP and convex QP problems using several alternative algorithms, while the only choice for solving convex QCP is the parallel barrier algorithm. The majority of LP problems solve best using Gurobi's state-of-the-art dual simplex algorithm, while most convex QP problems solve best using the parallel barrier algorithm. Certain types of LP problems benefit from using the parallel barrier or the primal simplex algorithms, while for some types of QP, the dual or primal simplex algorithm can be a better choice. If you are solving LP problems on a multi-core system, you should also consider using the concurrent optimizer. It runs different optimization algorithms on different cores, and returns when the first one finishes.

GAMS/Gurobi also provides access to the Gurobi infeasibility finder. The infeasibility finder takes an infeasible linear program and produces an irreducibly inconsistent set of constraints (IIS). An IIS is a set of constraints and variable bounds which is infeasible but becomes feasible if any one member of the set is dropped. GAMS/Gurobi reports the IIS in terms of GAMS equation and variable names and includes the IIS report as part of the normal solution listing. The infeasibility finder is activated by the option IIS. Another option for analyzing infeasible model the FeasOpt option which instructs GAMS/Gurobi to find a minimal feasible relaxation of an infeasible model. See section Feasible Relaxation for details.

GAMS/Gurobi supports sensitivity analysis (post-optimality analysis) for linear programs which allows one to find out more about an optimal solution for a problem. In particular, objective ranging and constraint ranging give information about how much an objective coefficient or a right-hand-side and variable bounds can change without changing the optimal basis. In other words, they give information about how sensitive the optimal basis is to a change in the objective function or the bounds and right-hand side. GAMS/Gurobi reports the sensitivity information as part of the normal solution listing. Sensitivity analysis is activated by the option Sensitivity.

The Gurobi presolve can sometimes diagnose a problem as being infeasible or unbounded. When this happens, GAMS/Gurobi can, in order to get better diagnostic information, rerun the problem with presolve turned off. The rerun without presolve is controlled by the option ReRun. In default mode only problems that are small (i.e. demo sized) will be rerun.

Gurobi can either presolve a model or start from an advanced basis or primal/dual solution pair. Often the solve from scratch of a presolved model outperforms a solve from an unpresolved model started from an advanced basis/solution. It is impossible to determine a priori if presolve or starting from a given advanced basis/solution without presolve will be faster. By default, GAMS/Gurobi will automatically use an advanced basis or solution from a previous solve statement. The GAMS BRatio option can be used to specify when not to use an advanced basis/solution. The GAMS/Gurobi option UseBasis can be used to ignore or force a basis/solution passed on by GAMS (it overrides BRatio). In case of multiple solves in a row and slow performance of the second and subsequent solves, the user is advised to set the GAMS BRatio option to 1.

Mixed-Integer Programming

The methods used to solve pure integer and mixed integer programming problems require dramatically more mathematical computation than those for similarly sized pure linear or quadratic programs. Many relatively small integer programming models take enormous amounts of time to solve.

For problems with discrete variables, Gurobi uses a branch and cut algorithm which solves a series of subproblems, LP subproblems for MILP, QP subproblems for MIQP, and QCP subproblems or LP outer approximation subproblems for MIQCP. Because a single mixed integer problem generates many subproblems, even small mixed integer problems can be very compute intensive and require significant amounts of physical memory. With option nonConvex Gurobi can also solve nonconvex (MI)QP and (MI)QCP problems using a spatial branch-and-bound method.

GAMS/Gurobi supports Special Order Sets of type 1 and type 2 as well as semi-continuous and semi-integer variables.

You can provide a known solution (for example, from a MIP problem previously solved or from your knowledge of the problem) to serve as the first integer solution.

If you specify some or all values for the discrete variables together with GAMS/Gurobi option MipStart, Gurobi will check the validity of the values as an integer-feasible solution. If this process succeeds, the solution will be treated as an integer solution of the current problem.

The Gurobi MIP solver includes shared memory parallelism, capable of simultaneously exploiting any number of processors and cores per processor. The implementation is deterministic: two separate runs on the same model will produce identical solution paths.

Nonlinear Programming

GAMS/Gurobi primarily uses Gurobi's nonlinear function interface. If passing the constraint through that interface is not possible (or if trynonlin is disabled), GAMS/Gurobi tries Gurobi's other general constraints. For the former, the constraint doesn't need to be in any special form but must contain functions that are supported by Gurobi's nonlinear interface. For the latter, the constraint must be in any of the forms listed below.

• MAX constraint:

  eq1.. r =e= max(x1,x2,x3,...,c);
  eq2.. r =e= smax(i, x(i));
  

• MIN constraint:

  eq1.. r =e= min(x1,x2,x3,...,c);
  eq2.. r =e= smin(i, x(i));
  

• AND constraint:

  eq1.. r =e= b1 and b2 and b3 and ...;
  eq2.. r =e= sand(i, b(i));
  

• OR constraint:

  eq1.. r =e= b1 or b2 or b3 or ...;
  eq2.. r =e= sor(i, b(i));
  

• ABS constraint:

  eq.. r =e= abs(x);
  

• EXP constraint:

  eq1.. r =e= exp(x);
  eq2.. r =e= x**a;
  eq3.. r =e= a**x;
  

  Here, a > 0 and for eq3 the lower bound of x must be nonnegative.
• LOG constraint:

  eq1.. r =e= log(x);
  eq2.. r =e= log2(x);
  eq3.. r =e= log10(x);
  

• SIN / COS / TAN constraint:

  eq1.. r =e= sin(x);
  eq2.. r =e= cos(x);
  eq3.. r =e= tan(x);
  

• NORM constraint:

  eq1_1.. r =e= sum(i, abs(x(i)));
  eq1_2.. r =e= abs(x1) + abs(x2) + abs(x3) + abs(x4);
  
  eq2_1.. r =e= edist(x1,x2,x3,...);
  eq2_2.. r =e= sqrt(sum(i, sqr(x(i))));
  eq2_3.. r =e= sqrt(sqr(x1) + sqr(x2) + sqr(x3) + sqr(x4));
  
  eq3_1.. r =e= smax(i, abs(x(i)));
  eq3_2.. r =e= max(abs(x1), abs(x2), abs(x3), abs(x4));
  

  Note that a 2-norm constraint can lead to a non-convex quadratic model which is much harder to solve than a convex quadratic or linear model.
• POLY constraint:

  eq.. r =e= poly(x, a0, a1, a2, ...);
  

• SIGMOID constraint:

  eq1.. r =e= sigmoid(x);
  eq2.. r =e= 1 / (1 + exp(-x));
  

Gurobi can solve (mixed-integer) nonlinear programs to global optimality either directly or by approximating the model by piecewise-linear functions and/or reformulating nonlinear constraints into supported linear and/or quadratic constraints (see also funcnonlinear.)

Feasible Relaxation

The Infeasibility Finder identifies the causes of infeasibility by means of inconsistent set of constraints (IIS). However, you may want to go beyond diagnosis to perform automatic correction of your model and then proceed with delivering a solution. One approach for doing so is to build your model with explicit slack variables and other modeling constructs, so that an infeasible outcome is never a possibility. An automated approach offered in GAMS/Gurobi is known as FeasOpt (for Feasible Optimization) and turned on by parameter FeasOpt in a GAMS/Gurobi option file.

With the FeasOpt option GAMS/Gurobi accepts an infeasible model and selectively relaxes the bounds and constraints in a way that minimizes a weighted penalty function. In essence, the feasible relaxation tries to suggest the least change that would achieve feasibility. It returns an infeasible solution to GAMS and marks the relaxations of bounds and constraints with the INFES marker in the solution section of the listing file.

By default all equations are candidates for relaxation and weighted equally but none of the variables can be relaxed. This default behavior can be modified by assigning relaxation preferences to variable bounds and constraints. These preferences can be conveniently specified with the .feaspref option. The input value denotes the users willingness to relax a constraint or bound. The larger the preference, the more likely it will be that a given bound or constraint will be relaxed. More precisely, the reciprocal of the specified value is used to weight the relaxation of that constraint or bound. The user may specify a preference value less than or equal to 0 (zero), which denotes that the corresponding constraint or bound must not be relaxed. It is not necessary to specify a unique preference for each bound or range. In fact, it is conventional to use only the values 0 (zero) and 1 (one) except when your knowledge of the problem suggests assigning explicit preferences.

Preferences can be specified through a GAMS/Gurobi solver option file using dot options. The syntax is:

(variable or equation).feaspref(value)

For example, suppose we have a GAMS declaration:

   Set i /i1*i5/;
   Set j /j2*j4/;
   variable v(i,j); equation e(i,j);

Then, the relaxation preference in the gurobi.opt file can be specified by:

feasopt 1
v.feaspref            1
v.feaspref('i1',*)    2
v.feaspref('i1','j2') 0

e.feaspref(*,'j1')    0
e.feaspref('i5','j4') 2

First we turn the feasible relaxation on. Futhermore, we specify that all variables v(i,j) have preference of 1, except variables over set element i1, which have a preference of 2. The variable over set element i1 and j2 has preference 0. Note that preferences are assigned in a procedural fashion so that preferences assigned later overwrite previous preferences. The same syntax applies for assigning preferences to equations as demonstrated above. If you want to assign a preference to all variables or equations in a model, use the keywords variables or equations instead of the individual variable and equations names (e.g. variables.feaspref 1).

The parameter FeasOptMode allows different strategies in finding feasible relaxation in one or two phases. In its first phase, it attempts to minimize its relaxation of the infeasible model. That is, it attempts to find a feasible solution that requires minimal change. In its second phase, it finds an optimal solution (using the original objective) among those that require only as much relaxation as it found necessary in the first phase. Values of the parameter FeasOptMode indicate two aspects: (1) whether to stop in phase one or continue to phase two and (2) how to measure the relaxation (as a sum of required relaxations; as the number of constraints and bounds required to be relaxed; as a sum of the squares of required relaxations). Please check description of parameter FeasOptMode for details. Also check example models feasopt* in the GAMS Model library.

Parameter Tuning Tool

The Gurobi Optimizer provides a wide variety of parameters that allow you to control the operation of the optimization engines. The level of control varies from extremely coarse-grained (e.g., the Method parameter, which allows you to choose the algorithm used to solve continuous models) to very fine-grained (e.g., the MarkowitzTol parameter, which allows you to adjust the precise tolerances used during simplex basis factorization). While these parameters provide a tremendous amount of user control, the immense space of possible options can present a significant challenge when you are searching for parameter settings that improve performance on a particular model. The purpose of the Gurobi tuning tool is to automate this search.

The Gurobi tuning tool performs multiple solves on your model, choosing different parameter settings for each, in a search for settings that improve runtime. The longer you let it run, the more likely it is to find a significant improvement.

A number of tuning-related parameters allow you to control the operation of the tuning tool. The most important is probably TuneTimeLimit, which controls the amount of time spent searching for an improving parameter set. Other parameters include TuneTrials (which attempts to limit the impact of randomness on the result), TuneResults (which limits the number of results that are returned), and TuneOutput (which controls the amount of output produced by the tool).

While parameter settings can have a big performance effect for many models, they aren't going to solve every performance issue. One reason is simply that there are many models for which even the best possible choice of parameter settings won't produce an acceptable result. Some models are simply too large and/or difficult to solve, while others may have numerical issues that can't be fixed with parameter changes.

Another limitation of automated tuning is that performance on a model can experience significant variations due to random effects (particularly for MIP models). This is the nature of search. The Gurobi algorithms often have to choose from among multiple, equally appealing alternatives. Seemingly innocuous changes to the model (such as changing the order of the constraint or variables), or subtle changes to the algorithm (such as modifying the random number seed) can lead to different choices. Often times, breaking a single tie in a different way can lead to an entirely different search. We've seen cases where subtle changes in the search produce 100X performance swings. While the tuning tool tries to limit the impact of these effects, the final result will typically still be heavily influenced by such issues.

The bottom line is that automated performance tuning is meant to give suggestions for parameters that could produce consistent, reliable improvements on your models. It is not meant to be a replacement for efficient modeling or careful performance testing.

Compute Server

The Gurobi Compute Server allows you to use one or more servers to offload all of your Gurobi computations.

Gurobi compute servers support queuing and load balancing. You can set a limit on the number of simultaneous jobs each compute server will run. When this limit has been reached, subsequent jobs will be queued. If you have multiple compute servers, the current job load is automatically balanced among the available servers. By default, the Gurobi job queue is serviced in a First-In, First-Out (FIFO) fashion. However, jobs can be given different priorities. Jobs with higher priorities are then selected from the queue before jobs with lower priorities.

Gurobi Compute Server licenses and software are not included in GAMS/Gurobi. Contact Gurobi directly to inquire about the software and license.

Distributed Parallel Algorithms

Gurobi Optimizer implements a number of distributed algorithms that allow you to use multiple machines to solve a problem faster. Available distributed algorithms are:

• A distributed MIP solver, which allows you to divide the work of solving a single MIP model among multiple machines. A manager machine passes problem data to a set of worker machines in order to coordinate the overall solution process.
• A distributed concurrent solver, which allows you to use multiple machines to solve an LP or MIP model. Unlike the distributed MIP solver, the concurrent solver doesn't divide the work associated with solving the problem among the machines. Instead, each machine uses a different strategy to solve the whole problem, with the hope that one strategy will be particularly effective and will finish much earlier than the others. For some problems, this concurrent approach can be more effective than attempting to divide up the work.
• Distributed parameter tuning, which automatically searches for parameter settings that improve performance on your optimization model. Tuning solves your model with a variety of parameter settings, measuring the performance obtained by each set, and then uses the results to identify the settings that produce the best overall performance. The distributed version of tuning performs these trials on multiple machines, which makes the overall tuning process run much faster.

These distributed parallel algorithms are designed to be almost entirely transparent to the user. The user simply modifies a few parameters, and the work of distributing the computation to multiple machines is handled behind the scenes by Gurobi.

Specifying the Worker Pool

Once you've set up a set of one or more distributed workers, you should list at least one of their names in the WorkerPool parameter. You can provide either machine names or IP addresses, and they should be comma-separated.

You can provide the worker access password through the WorkerPassword parameter. All servers in the worker pool must have the same access password.

Requesting Distributed Algorithms

Once you've set up the worker pool through the appropriate parameters, the last step to use a distributed algorithm is to set the TuneJobs, ConcurrentJobs, or DistributedMIPJobs parameter. These parameters are used to indicate how many distinct tuning, concurrent, or distributed MIP jobs should be started on the available workers.

If some of the workers in your worker pool are running at capacity when you launch a distributed algorithm, the algorithm won't create queued jobs. Instead, it will launch as many jobs as it can (up to the requested value), and it will run with these jobs.

These distributed algorithms have been designed to be nearly indistinguishable from the single machine versions. Our hope is that, if you know how to use the single machine version, you'll find it straightforward to use the distributed version. The distributed algorithms respect all of the usual parameters. For distributed MIP, you can adjust strategies, adjust tolerances, set limits, etc. For concurrent MIP, you can allow Gurobi to choose the settings for each machine automatically or specify a set of options. For distributed tuning, you can use the usual tuning parameters, including TuneTimeLimit, TuneTrails, and TuneOutput.

There are a few things to be aware of when using distributed algorithms, though. One relates to relative machine performance. Distributed algorithms work best if all of the workers give very similar performance. For example, if one machine in your worker pool were much slower than the others in a distributed tuning run, any parameter sets tested on the slower machine would appear to be less effective than if they were run on a faster machine. Similar considerations apply for distributed MIP and distributed concurrent. We strongly recommend that you use machines with very similar performance. Note that if your machines have similarly performing cores but different numbers of cores, we suggest that you use the Threads parameter to make sure that all machines use the same number of cores.

Logging for distributed MIP is very similar to the standard MIP logging. The main differences are in the progress section. The header for the standard MIP logging looks like this:

    Nodes    |    Current Node    |     Objective Bounds      |     Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time

By contrast, the distributed MIP header looks like this:

    Nodes    |    Current Node    |     Objective Bounds      |     Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | ParUtil Time

Instead of showing iterations per node, the last field in the distributed log shows parallel utilization. Specifically, it shows the fraction of the preceding time period (the time since the previous progress log line) that the workers spent actively processing MIP nodes.

Here is an example of a distributed MIP progress log:

    Nodes    |    Utilization     |     Objective Bounds      |     Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | ParUtil Time

H    0                          157344.61033          -      -          0s
H    0                          40707.729144          -      -          0s
H    0                          28468.534497          -      -          0s
H    0                          18150.083886          -      -          0s
H    0                          14372.871258          -      -          0s
H    0                          13725.475382          -      -          0s
     0     0 10543.7611    0   19 13725.4754 10543.7611  23.2%   99%    0s
*  266                          12988.468031 10543.7611  18.8%          0s
H 1503                          12464.099984 10630.6187  14.7%          0s
* 2350                          12367.608657 10632.7061  14.0%          1s
* 3360                          12234.641804 10641.4586  13.0%          1s
H 3870                          11801.185729 10641.4586  9.83%          1s

Ramp-up phase complete - continuing with instance 2 (best bd 10661)

 16928  2731 10660.9626    0   12 11801.1857 10660.9635  9.66%   99%    2s
 135654 57117 11226.5449   19   12 11801.1857 11042.3036  6.43%   98%    5s
 388736 135228 11693.0268   23   12 11801.1857 11182.6300  5.24%   96%   10s
 705289 196412     cutoff           11801.1857 11248.8963  4.68%   98%   15s
 1065224 232839 11604.6587   28   10 11801.1857 11330.2111  3.99%   98%   20s
 1412054 238202 11453.2202   31   12 11801.1857 11389.7119  3.49%   99%   25s
 1782362 209060     cutoff           11801.1857 11437.2670  3.08%   97%   30s
 2097018 158137 11773.6235   20   11 11801.1857 11476.1690  2.75%   92%   35s
 2468495 11516     cutoff           11801.1857 11699.9393  0.86%   78%   40s
 2481830     0     cutoff           11801.1857 11801.1857  0.00%   54%   40s

One thing you may find in the progress section is that node counts may not increase monotonically. Distributed MIP tries to create a single, unified view of node numbers, but with multiple machines processing nodes independently, possibly at different rates, some inconsistencies are inevitable.

Another difference is the line that indicates that the distributed ramp-up phase is complete. At this point, the distributed strategy transitions from a concurrent approach to a distributed approach. The log line indicates which worker was the winner in the concurrent approach. Distributed MIP continues by dividing the partially explored MIP search tree from this worker among all of the workers.

Another difference in the distributed log is in the summary section. The distributed MIP log includes a breakdown of how runtime was spent:

Runtime breakdown:
  Active:  37.85s (93%)
  Sync:     2.43s (6%)
  Comm:     0.34s (1%)

This is an aggregated view of the utilization data that is displayed in the progress log lines. In this example, the workers spent 93% of runtime actively working on MIP nodes, 6% waiting to synchronize with other workers, and 1% communicating data between machines.

The installation instructions for the Gurobi Remote Services can be found on Gurobi's web page [www.gurobi.com] (https://www.gurobi.com).

Gurobi Instant Cloud

An alternative to setting up your own pool of machines is to use the Gurobi Instant Cloud. You only need a GAMS/Gurobi link license when you solve your problems in the Gurobi Instant Cloud. The cost for the Gurobi license is paid on a per use basis directly to Gurobi. If you follow through the steps on the Gurobi web site, you eventually get the names of the machines Gurobi has started for you in the cloud. In order to use these machines from GAMS/Gurobi, you need to provide a Gurobi license with access instructions for the Gurobi Instant Cloud (detailed instructions for configuring the client license file).

Solution Pool

While the default goal of the Gurobi Optimizer is to find one proven optimal solution to your model, with a possible side-effect of finding other solutions along the way, the solver provides a number of parameters that allow you to change this behavior.

By default, the Gurobi MIP solver will try to find one proven optimal solution to your model. It will typically find multiple sub-optimal solutions along the way, which can be retrieved later. However, these solutions aren't produced in a systematic way. The set of solutions that are found depends on the exact path the solver takes through the MIP search. You could solve a MIP model once, obtaining a set of interesting sub-optimal solutions, and then solve the same problem again with different parameter settings, and find only the optimal solution.

To store (some of the) solutions found along the way, you can enable the Solution Pool feature by setting option solnpool. If you'd like more control over how solutions are found and retained, the Gurobi Optimizer has a number of parameters available for this. The first and simplest is PoolSolutions, which controls the size of the solution pool. Changing this parameter won't affect the number of solutions that are found - it simply determines how many of those are retained.

You can use the PoolSearchMode parameter to control the approach used to find solutions. In its default setting (0), the MIP search simply aims to find one optimal solution. Setting the parameter to 1 causes the MIP search to expend additional effort to find more solutions, but in a non-systematic way. You will get more solutions, but not necessarily the best solutions. Setting the parameter to 2 causes the MIP to do a systematic search for the n best solutions. For both non-default settings, the PoolSolutions parameter sets the target for the number of solutions to find.

If you are only interested in solutions that are within a certain gap of the best solution found, you can set the PoolGap parameter. Solutions that are not within the specified gap are discarded.

Obtaining an OPTIMAL optimization return status when using PoolSearchMode=2 indicates that the MIP solver succeeded in finding the desired number of best solutions, or it proved that the model doesn't have that many distinct feasible solutions. If the solver terminated early (e.g., due to a time limit), you PoolObjBound attribute (printed to the log) to evaluate the quality of the solutions that were found. This attribute gives a bound on the objective of any solution that isn't already in the solution pool. The difference between this attribute and ObjBound is that the latter gives a bound on the objective for any solution, and which is often looser than PoolObjBound. The PoolObjBound attribute gives a bound on the objective of undiscovered solutions. Further tree exploration won't find better solutions. You can use this bound to get a count of how many of the n best solutions you found: any solutions whose objective values are at least as good as PoolObjBound are among the n best.

Solution Pool Example

Let's continue with a few examples of how these parameters would be used. Imagine that you are solving a MIP model with an optimal (minimization) objective of 100. Further imagine that, using default settings, the MIP solver finds four solutions to this model with objectives 100, 110, 120, and 130.

If you set the PoolSolutions parameter to 3 and solve the model again, the MIP solver would discard the worst solution and return with 3 solutions in the solution pool. If you instead set the PoolGap parameter to value 0.2, the MIP solver would discard any solutions whose objective value is worse than 120 (which would also leave 3 solutions in the solution pool).

If you set the PoolSearchMode parameter to 2 and the PoolSolutions parameter to 10, the MIP solver would attempt to find the 10 best solutions to the model. An OPTIMAL return status would indicate that either (i) it found the 10 best solutions, or (ii) it found all feasible solutions to the model, and there were fewer than 10. If you also set the PoolGap parameter to a value of 0.1, the MIP solver would try to find 10 solutions with objective no worse than 110. While this may appear equivalent to asking for 10 solutions and simply ignoring those with objective worse than 110, the solve will typically complete significantly faster with this parameter set, since the solver does not have to expend effort looking for solutions beyond the requested gap.

Solution Pool Subtleties

There are a few subtleties associated with finding multiple solutions that we'll cover now.

Continuous Variables

One subtlety arises when considering multiple solutions for models with continuous variables. Specifically, you may have two solutions that take identical values on the integer variables but where some continuous variables differ. By choosing different points on the line between these two solutions, you actually have an infinite number of choices for feasible solutions to the problem. To avoid this issue, we define two solutions as being equivalent if they take the same values on all integer variables (and on all continuous variables that participate in SOS constraints). A solution will be discarded if it is equivalent to another solution that is already in the pool.

Optimality Gap

The interplay between the optimality gap (MIPGap or MIPGapAbs) and multiple solutions can be a bit subtle. When using the default PoolSearchMode, a non-zero optimality gap indicates that you are willing to allow the MIP solver to declare a solution optimal, even though the model may have other, better solutions. The claim the solver makes upon termination is that no other solution would improve the incumbent objective by more than the optimality gap. Terminating at this point is ultimately a pragmatic choice - we'd probably rather have the true best solution, but the cost of reducing the optimality gap to zero can often be prohibitive.

This pragmatic choice can produce a bit of confusion when finding multiple optimal solutions. Specifically, if you ask for the n best solutions, the optimality gap plays a similar role as it does in the default case, but the implications may be a bit harder to understand. Specifically, a non-zero optimality gap means that you are willing to allow the solver to declare that it has found the n best solutions, even though there may be solutions that are better than those that were returned. The claim in this case is that any solution not among the reported n best would improve on the objective for the worst among the n best by less than the optimality gap.

If you want to avoid this source of potential confusion, you should set the optimality gap to 0 when using PoolSearchMode=2.

Logging

If you browse the log from a MIP solve with PoolSearchMode set to a non-default value, you may see the lower bound on the objective exceed the upper bound. This can't happen with the default PoolSearchMode - if you are only looking for one optimal solution, the search is done as soon as the lower bound reaches the upper bound. However, if you are looking for the n best solutions, you have to prove that the model has no solution better than the n-th best. The objective for that n-th solution could be much worse than that of the incumbent. In this situation, the log file will include a line of the form:

Optimal solution found at node 123 - now completing solution pool...

Distributed MIP

One limitation that we should point out related to multiple solutions is that the distributed MIP solver has not been extended to support non-default PoolSearchMode settings. Distributed MIP will typically produce many more feasible solutions than non-distributed MIP, but there's no way to ask it to find the n best solutions.

Multiple Objectives

While typical optimization models have a single objective function, real-world optimization problems often have multiple, competing objectives. For example, in a production planning model, you may want to both maximize profits and minimize late orders, or in a workforce scheduling application, you may want to both minimize the number of shifts that are short-staffed while also respecting worker's shift preferences.

The main challenge you face when working with multiple, competing objectives is deciding how to manage the tradeoffs between them. Gurobi provides tools that simplify the task: Gurobi allows you to blend multiple objectives, to treat them hierarchically, or to combine the two approaches. In a blended approach, you optimize a weighted combination of the individual objectives. In a hierarchical or lexicographic approach, you set a priority for each objective, and optimize in priority order. When optimizing for one objective, you only consider solutions that would not degrade the objective values of higher-priority objectives. Gurobi allows you to enter and manage your objectives, to provide weights for a blended approach, or to set priorities for a hierarchical approach. Gurobi will only solve multi-objective models with strictly linear objectives. Moreover, for continuous models, Gurobi will report a primal only solution (not dual information).

Following the workforce application the specifications of the objectives would be done as follows:

equations defObj, defNumShifts, defSumPreferences;
variables obj, numShifts, sumPreferences;

defobj..            obj =e= numShifts - 1/100*sumPreferences;
defNumShifts..      numShifts =e= ...;
defSumPreferences.. sumPreferences =e= ...;

model workforce /all/;
solve workforce minimizing obj using mip;

With the default setting GUROBI will solve the blended objective. Using the parameter MultObj GUROBI will use a hierarchical approach. A hierarchical or lexicographic approach assigns a priority to each objective, and optimizes for the objectives in decreasing priority order. At each step, it finds the best solution for the current objective, but only from among those that would not degrade the solution quality for higher-priority objectives. The priority is specified by the absolute value of the objective coefficient in the blended objective function (defObj). In the example, the numShifts objective with coefficient 1 has higher priority than the sumPreferences objective with absolute objective coefficient 1/100. The sign of the objective coefficient determines the direction of the particular objective function. So here numShifts will be minimized (same direction as on the solve statement) while sumPreferences will be maximized. GAMS needs to identify the various objective functions, therefore the objective variables can only appear in the blended objective functions and in the particular objective defining equation.

By default, the hierarchical approach won't allow later objectives to degrade earlier objectives. This behavior can be relaxed through a pair of attributes: ObjNRelTol and ObjNAbsTol. By setting one of these for a particular objective, you can indicate that later objectives are allowed to degrade this objective by the specified relative or absolute amount, respectively. In our earlier example, if the optimal value for numShifts is 100, and if we set ObjNAbsTol for this objective to 20, then the second optimization step maximizing sumPreferences would find the best solution for the second objective from among all solutions with objective 120 or better for numShifts. Note that if you modify both tolerances, later optimizations would use the looser of the two values (i.e., the one that allows the larger degradation).

GAMS Options

The following GAMS options are used by GAMS/Gurobi:

Option BRatio = x;

Determines whether or not to use an advanced basis. A value of 1.0 causes GAMS to instruct Gurobi not to use an advanced basis. A value of 0.0 causes GAMS to construct a basis from whatever information is available. The default value of 0.25 will nearly always cause GAMS to pass along an advanced basis if a solve statement has previously been executed. This GAMS option is overridden by the GAMS/Gurobi option UseBasis

Option IterLim = n;

Sets the simplex iteration limit. Simplex algorithms will terminate and pass on the current solution to GAMS. For MIP problems, if the number of the cumulative simplex iterations exceeds the limit, Gurobi will terminate. This GAMS option is overridden by the GAMS/Gurobi option IterationLimit

Option NodLim = x;

Maximum number of nodes to process for a MIP problem. This GAMS option is overridden by the GAMS/Gurobi option NodeLimit.

Option OptCA = x;

Absolute optimality criterion for a MIP problem. The OptCA option asks Gurobi to stop when

\begin{equation*} |BP - BF| < \mbox{OptCA} \end{equation*}

where BF is the objective function value of the current best integer solution while BP is the best possible integer solution. This GAMS option is overridden by the GAMS/Gurobi option MipGapAbs.

Option OptCR = x;

Relative optimality criterion for a MIP problem. Notice that Gurobi uses a different definition than GAMS normally uses. The OptCR option asks Gurobi to stop when

\begin{equation*} |BP - BF| < |BF|*\mbox{OptCR} \end{equation*}

where BF is the objective function value of the current best integer solution while BP is the best possible integer solution. The GAMS definition is:

\begin{equation*} |BP - BF| < |BP|*\mbox{OptCR} \end{equation*}

This GAMS option is overridden by the GAMS/Gurobi option MipGap.

Option ResLim = x;

Sets the time limit in seconds. The algorithm will terminate and pass on the current solution to GAMS. Gurobi measures time in wall time on all platforms. Some other GAMS solvers measure time in CPU time on some Unix systems. In case resLim assumes its default value (1e+10) Gurobi will use its own default (infinity). This GAMS option is overridden by the GAMS/Gurobi option TimeLimit.

Option SysOut = On;

Will echo Gurobi messages to the GAMS listing file. This option may be useful in case of a solver failure.

ModelName.Cutoff = x;

Cutoff value. When the branch and bound search starts, the parts of the tree with an objective worse than x are deleted. This can sometimes speed up the initial phase of the branch and bound algorithm. This GAMS option is overridden by the GAMS/Gurobi option CutOff.

ModelName.OptFile = 1;

Instructs GAMS/Gurobi to read the option file. The name of the option file is gurobi.opt.

ModelName.PriorOpt = 1;

Instructs GAMS/Gurobi to use the priority branching information passed by GAMS through variable suffix values variable.prior.

Summary of GUROBI Options

Termination options

Option	Description	Default
bariterlimit	Barrier iteration limit	infinity
bestbdstop	Best objective bound to stop	maxdouble
bestobjstop	Best objective value to stop	mindouble
cutoff	Objective cutoff	maxdouble
iterationlimit	Simplex iteration limit	infinity
memlimit	Memory limit	maxdouble
nlbariterlimit	NL barrier iteration limit	1000
nodelimit	MIP node limit	maxdouble
pdhgiterlimit	PDHG iteration limit	maxdouble
softmemlimit	Soft memory limit	maxdouble
solutionlimit	MIP feasible solution limit	maxint
timelimit	Time limit	GAMS reslim
worklimit	Work limit	maxdouble

Tolerances options

Option	Description	Default
barconvtol	Barrier convergence tolerance	1e-08
barqcpconvtol	Barrier QCP convergence tolerance	1e-06
feasibilitytol	Primal feasibility tolerance	1e-06
intfeastol	Integer feasibility tolerance	1e-05
markowitztol	Threshold pivoting tolerance	0.0078125
mipgap	Relative MIP optimality gap	GAMS optcr
mipgapabs	Absolute MIP optimality gap	GAMS optca
nlbarcfeastol	NL barrier complementarity tolerance	1e-08
nlbardfeastol	NL barrier dual feasibility tolerance	1e-06
nlbarpfeastol	NL barrier primal feasibility tolerance	1e-06
optimalitytol	Dual feasibility tolerance	1e-06
pdhgabstol	PDHG absolute feasibility tolerance	1e-06
pdhgconvtol	PDHG convergence tolerance	1e-06
pdhgreltol	PDHG relative feasibility tolerance	1e-06
psdtol	Positive semi-definite tolerance	1e-06

Logging options

Option	Description	Default
displayinterval	Frequency at which log lines are printed	5

Output options

Option	Description	Default
solfiles	Location to store intermediate solution files

Presolve options

Option	Description	Default
aggfill	Allowed fill during presolve aggregation	-1
aggregate	Presolve aggregation control	1
dualreductions	Disables dual reductions in presolve	1
precrush	Allows presolve to translate constraints on the original model to equivalent constraints on the presolved model	0
predeprow	Presolve dependent row reduction	-1
predual	Presolve dualization	-1
premiqcpform	Format of presolved MIQCP model	-1
prepasses	Presolve pass limit	-1
preqlinearize	Presolve Q matrix linearization	-1
Presolve	Presolve level	-1
presos1bigm	Controls largest coefficient in SOS1 reformulation	-1
presos1encoding	Controls SOS1 reformulation	-1
presos2bigm	Controls largest coefficient in SOS2 reformulation	-1
presos2encoding	Controls SOS2 reformulation	-1
presparsify	Presolve sparsify reduction	-1

Simplex options

Option	Description	Default
lpwarmstart	Warm start usage in simplex	-1
method	Define method, e.g., Simplex, to solve continuous models	-1
networkalg	Network simplex algorithm	-1
normadjust	Simplex pricing norm	-1
perturbvalue	Simplex perturbation magnitude	0.0002
quad	Quad precision computation in simplex	-1
sifting	Sifting within dual simplex	-1
siftmethod	LP method used to solve sifting sub-problems	-1
simplexpricing	Simplex variable pricing strategy	-1

Barrier options

Option	Description	Default
barcorrectors	Central correction limit	-1
barhomogeneous	Barrier homogeneous algorithm	-1
barorder	Barrier ordering algorithm	-1
crossover	Barrier crossover strategy	-1
crossoverbasis	Crossover initial basis construction strategy	-1
qcpdual	Compute dual variables for QCP models	0

Scaling options

Option	Description	Default
objscale	Objective scaling	0
scaleflag	Model scaling	-1

MIP options

Option	Description	Default
branchdir	Branch direction preference	0
concurrentjobs	Enables distributed concurrent solver	0
concurrentmethod	Chooses continuous solvers to run concurrently	-1
concurrentmip	Enables concurrent MIP solver	1
degenmoves	Degenerate simplex moves	-1
disconnected	Disconnected component strategy	-1
distributedmipjobs	Enables the distributed MIP solver	0
dumpbcsol	Dump incumbents to GDX files during branch-and-cut
fixoptfile	Option file for fixed problem optimization
fixvarsinindicators	Controls conversion of indicator constraints in the fixed model	0
heuristics	Turn MIP heuristics up or down	0.05
improvestartgap	Trigger solution improvement	0
improvestartnodes	Trigger solution improvement	maxdouble
improvestarttime	Trigger solution improvement	maxdouble
improvestartwork	Trigger solution improvement	maxdouble
integralityfocus	Set the integrality focus	0
.lazy	Lazy constraints value	0
lazyconstraints	Indicator to use lazy constraints	0
minrelnodes	Minimum relaxation heuristic control	-1
mipfocus	Set the focus of the MIP solver	0
mipstart	Use mip starting values	0
mipstopexpr	Stop expression for branch and bound
miqcpmethod	Method used to solve MIQCP models	-1
multimipstart	Use multiple (partial) mipstarts provided via gdx files
nlpheur	Controls the NLP heuristic for non-convex quadratic models	-1
nodefiledir	Directory for MIP node files	.
nodefilestart	Memory threshold for writing MIP tree nodes to disk	maxdouble
nodemethod	Method used to solve MIP node relaxations	-1
nonconvex	Control how to deal with non-convex quadratic programs	-1
norelheurtime	Limits the amount of time (in seconds) spent in the NoRel heuristic	0
norelheurwork	Limits the amount of work performed by the NoRel heuristic	0
obbt	Controls aggressiveness of optimality-based bound tightening	-1
.partition	Variable partition value	0
partitionplace	Controls when the partition heuristic runs	15
.prior	Branching priorities	1
pumppasses	Feasibility pump heuristic control	-1
rins	RINS heuristic	-1
solnpool	Controls export of alternate MIP solutions
solnpoolmerge	Controls export of alternate MIP solutions for merged GDX solution file
solnpoolnumsym	Maximum number of variable symbols when writing merged GDX solution file	10
solnpoolprefix	First dimension of variables for merged GDX solution file or file name prefix for GDX solution files	soln
solvefixed	Indicator for solving the fixed problem for a MIP to get a dual solution	1
startnodelimit	Node limit for MIP start sub-MIP	-1
starttimelimit	Time limit for MIP start sub-MIP (in seconds)	maxdouble
startworklimit	Work limit for MIP start sub-MIP (in work units)	maxdouble
submipnodes	Nodes explored by sub-MIP heuristics	500
symmetry	Symmetry detection	-1
varbranch	Branch variable selection strategy	-1
zeroobjnodes	Zero objective heuristic control	-1

MIP Cuts options

Option	Description	Default
bqpcuts	BQP cut generation	-1
cliquecuts	Clique cut generation	-1
covercuts	Cover cut generation	-1
cutaggpasses	Constraint aggregation passes performed during cut generation	-1
cutpasses	Root cutting plane pass limit	-1
cuts	Global cut generation control	-1
dualimpliedcuts	Dual implied bound cut generation	-1
flowcovercuts	Flow cover cut generation	-1
flowpathcuts	Flow path cut generation	-1
gomorypasses	Root Gomory cut pass limit	-1
gubcovercuts	GUB cover cut generation	-1
impliedcuts	Implied bound cut generation	-1
infproofcuts	Infeasibility proof cut generation	-1
liftprojectcuts	Lift-and-project cut generation	-1
masterknapsackcuts	Master Knapsack Polytope cut generation	-1
mipsepcuts	MIP separation cut generation	-1
mircuts	MIR cut generation	-1
mixingcuts	Mixing cut generation	-1
modkcuts	Mod-k cut generation	-1
networkcuts	Network cut generation	-1
projimpliedcuts	Projected implied bound cut generation	-1
psdcuts	PSD cut generation	-1
relaxliftcuts	Relax-and-lift cut generation	-1
rltcuts	RLT cut generation	-1
strongcgcuts	Strong-CG cut generation	-1
submipcuts	Sub-MIP cut generation	-1
zerohalfcuts	Zero-half cut generation	-1

Numerics options

Option	Description	Default
numericfocus	Set the numerical focus	0

Tuning options

Option	Description	Default
tunecleanup	Enables a tuning cleanup phase	0
tunecriterion	Specify tuning criterion	-1
tunedynamicjobs	Enables distributed tuning using a dynamic set of workers	0
tunejobs	Enables distributed tuning using a static set of workers	0
tunemetric	Metric to aggregate results into a single measure	-1
tuneoutput	Tuning output level	2
tuneresults	Number of improved parameter sets returned	-1
tunetargetmipgap	A target gap to be reached	0
tunetargettime	A target runtime in seconds to be reached	0.005
tunetimelimit	Time limit for tuning	86400
tunetrials	Perform multiple runs on each parameter set to limit the effect of random noise	0

Multiple Solutions options

Option	Description	Default
poolgap	Relative gap for solutions in pool	maxdouble
poolgapabs	Absolute gap for solutions in pool	maxdouble
poolsearchmode	Choose the approach used to find additional solutions	0
poolsolutions	Number of solutions to keep in pool	10

Multiple Objectives options

Option	Description	Default
multiobjmethod	Warm-start method to solve for subsequent objectives	-1
multiobjpre	Initial presolve on multi-objective models	-1

Parallel and Distributed Computing options

Option	Description	Default
threads	Number of parallel threads to use	GAMS threads
workerpassword	Password for distributed worker cluster
workerpool	Distributed worker cluster

Miscellaneous options

Option	Description	Default
.dofuncpieceerror	Error allowed for PWL translation of function constraints	1e-3
.dofuncpiecelength	Piece length for PWL translation of function constraints	1e-2
.dofuncpieceratio	Control whether to under- or over-estimate function values in PWL approximation	-1
.dofuncpieces	Sets strategy for PWL function approximation	0
feasopt	Computes a minimum-cost relaxation to make an infeasible model feasible	0
feasoptmode	Mode of FeasOpt	0
.feaspref	feasibility preference	1
feasrelaxbigm	Big-M value for feasibility relaxations	1e+06
freegamsmodel	Preserves memory by dumping the GAMS model instance representation temporarily to disk	0
funcmaxval	Maximum value for x and y variables in function constraints	1e+06
funcnonlinear	Chooses the approximation approach used to handle function constraints	1
funcpieceerror	Error allowed for PWL translation of function constraint	0.001
funcpiecelength	Piece length for PWL translation of function constraint	0.01
funcpieceratio	Controls whether to under- or over-estimate function values in PWL approximation	-1
funcpieces	Sets strategy for PWL function approximation	0
iis	Run the Irreducible Inconsistent Subsystem (IIS) finder if the problem is infeasible	0
iismethod	IIS method	-1
kappa	Display approximate condition number estimates for the optimal simplex basis	0
kappaexact	Display exact condition number estimates for the optimal simplex basis	0
miptrace	Filename of MIP trace file
miptracenode	Node interval when a trace record is written	100
miptracetime	Time interval when a trace record is written	1
multobj	Controls the hierarchical optimization of multiple objectives	0
names	Indicator for loading names	1
norelheursolutions	Limits the number of solutions found by the NoRel heuristic	0
objnabstol	Allowable absolute degradation for objective
objnreltol	Allowable relative degradation for objective
optimalitytarget	Controls the strategy to solve continuous nonlinear nonconvex models	-1
printoptions	List values of all options to GAMS listing file	0
qextractalg	quadratic extraction algorithm in GAMS interface	0
qextractdenseswitchfactor	Sparse/dense factor for quadratic extraction algorithm in GAMS interface	0.008
qextractdenseswitchlog	Enables additional information about sparse/dense factor choice in quadratic extraction algorithm in GAMS interface	0
readparams	Read Gurobi parameter file
rerun	Resolve without presolve in case of unbounded or infeasible	-1
rngrestart	Write GAMS readable ranging information file
seed	Modify the random number seed	0
sensitivity	Provide sensitivity information	0
solutiontarget	Specify the solution target for LP	-1
.trynonlin	Try nonlinear function general constraint interface for nonlinear constraint	1
Tuning	Parameter Tuning
usebasis	Use basis from GAMS	GAMS bratio
varhint	Guide heuristics and branching through variable hints	0
writeparams	Write Gurobi parameter file
writeprob	Save the problem instance

The GAMS/Gurobi Options File

The GAMS/Gurobi options file consists of one option or comment per line. An asterisk (*) at the beginning of a line causes the entire line to be ignored. Otherwise, the line will be interpreted as an option name and value separated by any amount of white space (blanks or tabs).

Following is an example options file gurobi.opt.

     simplexpricing 3
     method 0

It will cause Gurobi to use quick-start steepest edge pricing and will use the primal simplex algorithm.

GAMS/Gurobi Log File

Gurobi reports its progress by writing to the GAMS log file as the problem solves. Normally the GAMS log file is directed to the computer screen.

The log file shows statistics about the presolve and continues with an iteration log.

For the simplex algorithms, each log line starts with the iteration number, followed by the objective value, the primal and dual infeasibility values, and the elapsed wall clock time. The dual simplex uses a bigM approach for handling infeasibility, so the objective and primal infeasibility values can both be very large during phase I. The frequency at which log lines are printed is controlled by the DisplayInterval option. By default, the simplex algorithms print a log line roughly every five seconds, although log lines can be delayed when solving models with particularly expensive iterations.

The simplex screen log has the following appearance:

Presolve removed 977 rows and 1539 columns
Presolve changed 3 inequalities to equalities
Presolve time: 0.078000 sec.
Presolved: 1748 Rows, 5030 Columns, 32973 Nonzeros

Iteration    Objective       Primal Inf.    Dual Inf.      Time
       0    3.8929476e+31   1.200000e+31   1.485042e-04      0s
    5624    1.1486966e+05   0.000000e+00   0.000000e+00      2s

Solved in 5624 iterations and 1.69 seconds
Optimal objective  1.148696610e+05

The barrier algorithm log file starts with barrier statistics about dense columns, free variables, nonzeros in AA' and the Cholesky factor matrix, computational operations needed for the factorization, memory estimate and time estimate per iteration. Then it outputs the progress of the barrier algorithm in iterations with the primal and dual objective values, the magnitude of the primal and dual infeasibilites and the magnitude of the complementarity violation. After the barrier algorithm terminates, by default, Gurobi will perform crossover to obtain a valid basic solution. It first prints the information about pushing the dual and primal superbasic variables to the bounds and then the information about the simplex progress until the completion of the optimization.

The barrier screen log has the following appearance:

Presolve removed 2394 rows and 3412 columns
Presolve time: 0.09s
Presolved: 3677 Rows, 8818 Columns, 30934 Nonzeros

Ordering time: 0.20s

Barrier statistics:
 Dense cols : 10
 Free vars  : 3
 AA' NZ     : 9.353e+04
 Factor NZ  : 1.139e+06 (roughly 14 MBytes of memory)
 Factor Ops : 7.388e+08 (roughly 2 seconds per iteration)

                  Objective                Residual
Iter       Primal          Dual         Primal    Dual     Compl     Time
   0   1.11502515e+13 -3.03102251e+08  7.65e+05 9.29e+07  2.68e+09     2s
   1   4.40523949e+12 -8.22101865e+09  3.10e+05 4.82e+07  1.15e+09     3s
   2   1.18016996e+12 -2.25095257e+10  7.39e+04 1.15e+07  3.37e+08     4s
   3   2.24969338e+11 -2.09167762e+10  1.01e+04 2.16e+06  5.51e+07     5s
   4   4.63336675e+10 -1.44308755e+10  8.13e+02 4.30e+05  9.09e+06     6s
   5   1.25266057e+10 -4.06364070e+09  1.52e+02 8.13e+04  2.21e+06     7s
   6   1.53128732e+09 -1.27023188e+09  9.52e+00 1.61e+04  3.23e+05     9s
   7   5.70973983e+08 -8.11694302e+08  2.10e+00 5.99e+03  1.53e+05    10s
   8   2.91659869e+08 -4.77256823e+08  5.89e-01 5.96e-08  8.36e+04    11s
   9   1.22358325e+08 -1.30263121e+08  6.09e-02 7.36e-07  2.73e+04    12s
  10   6.47115867e+07 -4.50505785e+07  1.96e-02 1.43e-06  1.18e+04    13s
  ......
  26   1.12663966e+07  1.12663950e+07  1.85e-07 2.82e-06  1.74e-04     2s
  27   1.12663961e+07  1.12663960e+07  3.87e-08 2.02e-07  8.46e-06     2s

Barrier solved model in 27 iterations and 1.86 seconds
Optimal objective 1.12663961e+07

Crossover log...

    1592 DPushes remaining with DInf 0.0000000e+00                 2s
       0 DPushes remaining with DInf 2.8167333e-06                 2s

     180 PPushes remaining with PInf 0.0000000e+00                 2s
       0 PPushes remaining with PInf 0.0000000e+00                 2s

  Push phase complete: Pinf 0.0000000e+00, Dinf 2.8167333e-06      2s

Iteration    Objective       Primal Inf.    Dual Inf.      Time
    1776    1.1266396e+07   0.000000e+00   0.000000e+00      2s

Solved in 2043 iterations and 2.00 seconds
Optimal objective  1.126639605e+07

For MIP problems, the Gurobi solver prints regular status information during the branch and bound search. The first two output columns in each log line show the number of nodes that have been explored so far in the search tree, followed by the number of nodes that remain unexplored. The next three columns provide information on the most recently explored node in the tree. The solver prints the relaxation objective value for this node, followed by its depth in the search tree, followed by the number of integer variables with fractional values in the node relaxation solution. The next three columns provide information on the progress of the global MIP bounds. They show the objective value for the best known integer feasible solution, the best bound on the value of the optimal solution, and the gap between these lower and upper bounds. Finally, the last two columns provide information on the amount of work performed so far. The first column gives the average number of simplex iterations per explored node, and the next column gives the elapsed wall clock time since the optimization began.

At the default value for option DisplayInterval, the MIP solver prints one log line roughly every five seconds. Note, however, that log lines are often delayed in the MIP solver due to particularly expensive nodes or heuristics.

Presolve removed 12 rows and 11 columns
Presolve tightened 70 bounds and modified 235 coefficients
Presolve time: 0.02s
Presolved: 114 Rows, 116 Columns, 424 Nonzeros
Objective GCD is 1

    Nodes    |    Current Node    |     Objective Bounds      |    Work
 Expl Unexpl |  Obj  Depth IntInf | Incumbent    BestBd   Gap | It/Node Time

H    0     0                         -0.0000          -     -      -    0s
Root relaxation: 208 iterations, 0.00 seconds
     0     0    29.6862    0   64    -0.0000    29.6862     -      -    0s
H    0     0                          8.0000    29.6862   271%     -    0s
H    0     0                         17.0000    29.6862  74.6%     -    0s
     0     2    27.4079    0   60    17.0000    27.4079  61.2%     -    0s
H   27    17                         18.0000    26.0300  44.6%  51.6    0s
*   87    26              45         20.0000    26.0300  30.2%  28.4    0s
*  353    71              29         21.0000    25.0000  19.0%  19.3    0s
  1268   225    24.0000   28   43    21.0000    24.0000  14.3%  32.3    5s
  2215   464    22.0000   43   30    21.0000    24.0000  14.3%  33.2   10s

Cutting planes:
  Gomory: 175
  Cover: 25
  Implied bound: 87
  MIR: 150

Explored 2550 nodes (84600 simplex iterations) in 11.67 seconds
Thread count was 1 (of  4 available processors)

Optimal solution found (tolerance 1.00e-01)
Best objective 2.1000000000e+01, best bound 2.3000000000e+01, gap 9.5238%

Detailed Descriptions of GUROBI Options

aggfill (integer): Allowed fill during presolve aggregation ↵

Controls the amount of fill allowed during presolve aggregation. Larger values generally lead to presolved models with fewer rows and columns, but with more constraint matrix non-zeros.

The default value chooses automatically, and usually works well.

See also Gurobi Documentation.

Default: -1

aggregate (integer): Presolve aggregation control ↵

See also Gurobi Documentation.

Default: 1

value	meaning
0	off
1	moderate
2	or aggressive

barconvtol (real): Barrier convergence tolerance ↵

The barrier solver terminates with a Optimal status when some solution quality attributes are less than the specified tolerance. The algorithm considers the relative difference between the primal and dual objective values, relative primal and dual feasiblity, and complementarity. Tightening this tolerance often produces a more accurate solution, which can sometimes reduce the time spent in crossover. Be aware that such tightening may result in an increase of barrier iterations and hence computation time spent therein. Loosening it causes the barrier algorithm to terminate with a less accurate solution, which can be useful when barrier is making very slow progress in later iterations but increases chances of prolonged runtime in crossover.

This parameter does not affect models with quadratic constraints. For these models use barqcpconvtol.

Note: Barrier only

See also Gurobi Documentation.

Default: 1e-08

barcorrectors (integer): Central correction limit ↵

Limits the number of central corrections performed in each barrier iteration. The default value chooses automatically, depending on problem characteristics. The automatic strategy generally works well, although it is often possible to obtain higher performance on a specific model by selecting a value manually.

Note: Barrier only

See also Gurobi Documentation.

Default: -1

barhomogeneous (integer): Barrier homogeneous algorithm ↵

Determines whether to use the homogeneous barrier algorithm. At the default setting (-1), it is only used when barrier solves a node relaxation for a MIP model. Setting the parameter to 0 turns it off, and setting it to 1 forces it on. The homogeneous algorithm is useful for recognizing infeasibility or unboundedness. It is a bit slower than the default algorithm.

Note: Barrier only

See also Gurobi Documentation.

Default: -1

bariterlimit (integer): Barrier iteration limit ↵

Limits the number of barrier iterations performed. This parameter is rarely used. If you would like barrier to terminate early, it is almost always better to use the barconvtol parameter instead.

Optimization returns with an Iteration Interrupt status if the limit is exceeded.

Note: Barrier only

See also Gurobi Documentation.

Default: infinity

barorder (integer): Barrier ordering algorithm ↵

Chooses the barrier sparse matrix fill-reducing algorithm. A value of 0 chooses Approximate Minimum Degree ordering, while a value of 1 chooses Nested Dissection ordering. The default value of -1 chooses automatically. You should only modify this parameter if you notice that the barrier ordering phase is consuming a significant fraction of the overall barrier runtime.

Note: Barrier only

See also Gurobi Documentation.

Default: -1

barqcpconvtol (real): Barrier QCP convergence tolerance ↵

When solving a QCP model, the barrier solver terminates with a Optimal status when some solution quality attributes are less than the specified tolerance. The algorithm considers the relative difference between the primal and dual objective values, relative primal and dual feasiblity, and complementarity. Tightening this tolerance may lead to a more accurate solution, but it may also lead to a failure to converge.

Note: Barrier only

See also Gurobi Documentation.

Default: 1e-06

bestbdstop (real): Best objective bound to stop ↵

Terminates as soon as the engine determines that the best bound on the objective value is at least as good as the specified value. Optimization returns with an Terminated by Solver status in this case.

Note that you should always include a small tolerance in this value. Without this, a bound that satisfies the intended termination criterion may not actually lead to termination due to numerical round-off in the bound.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

bestobjstop (real): Best objective value to stop ↵

Terminate as soon as the engine finds a feasible solution whose objective value is at least as good as the specified value. Optimization returns with an Terminated by Solver status in this case.

Note that you should always include a small tolerance in this value. Without this, a solution that satisfies the intended termination criterion may not actually lead to termination due to numerical round-off in the objective.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: mindouble

bqpcuts (integer): BQP cut generation ↵

Controls Boolean Quadric Polytope (BQP) cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

branchdir (integer): Branch direction preference ↵

Determines which child node is explored first in the branch-and-cut search. The default value chooses automatically. A value of -1 will always explore the down branch first, while a value of 1 will always explore the up branch first.

Changing the value of this parameter rarely produces a significant benefit.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

cliquecuts (integer): Clique cut generation ↵

Controls clique cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value choose automatically. Overrides the cuts parameter.

Gurobi has observed that setting this parameter to its aggressive setting can produce a significant benefit for some large set partitioning models.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

concurrentjobs (integer): Enables distributed concurrent solver ↵

Enables distributed concurrent optimization, which can be used to solve LP or MIP models on multiple machines. A value of n causes the solver to create n independent models, using different parameter settings for each. Each of these models is sent to a distributed worker for processing. Optimization terminates when the first solve completes. Use the ComputeServer parameter to indicate the name of the cluster where you would like your distributed concurrent job to run (or use WorkerPool if your client machine will act as manager and you just need a pool of workers).

By default, Gurobi chooses the parameter settings used for each independent solve automatically. You can create concurrent environments to choose your own parameter settings (refer to the concurrent optimization section for details). The intent of concurrent MIP solving is to introduce additional diversity into the MIP search. By bringing the resources of multiple machines to bear on a single model, this approach can sometimes solve models much faster than a single machine.

The distributed concurrent solver produces a slightly different log from the standard solver, and provides different callbacks as well. Please refer to the Distributed Algorithms section of the Gurobi Remote Services Reference Manual for additional details.

See also Gurobi Documentation.

Default: 0

concurrentmethod (integer): Chooses continuous solvers to run concurrently ↵

This parameter is only evaluated when solving an LP with a concurrent solver (method = 3 or 4). It controls which methods are run concurrently by the concurrent solver.

Which methods are actually run also depends on the number of threads available.

See also Gurobi Documentation.

Default: -1

value	meaning
-1	automatic
0	barrier, dual, primal simplex
1	barrier and dual simplex
2	barrier and primal simplex
3	dual and primal simplex

concurrentmip (integer): Enables concurrent MIP solver ↵

This parameter enables the concurrent MIP solver. When the parameter is set to value n, the MIP solver performs n independent MIP solves in parallel, with different parameter settings for each. Optimization terminates when the first solve completes.

By default, Gurobi chooses the parameter settings used for each independent solve automatically. You can create concurrent environments to choose your own parameter settings (refer to the concurrent optimization section for details). The intent of concurrent MIP solving is to introduce additional diversity into the MIP search. This approach can sometimes solve models much faster than applying all available threads to a single MIP solve, especially on very large parallel machines.

The concurrent MIP solver divides available threads evenly among the independent solves. For example, if you have 6 threads available and you set concurrentmip to 2, the concurrent MIP solver will allocate 3 threads to each independent solve. Note that the number of independent solves launched will not exceed the number of available threads.

The concurrent MIP solver produces a slightly different log from the standard MIP solver, and provides different callbacks as well. Please refer to the concurrent optimizer discussion for additional details.

Concurrent MIP is not deterministic. If runtimes for different independent solves are very similar, and if the model has multiple optimal solutions, you may get slightly different results from multiple runs on the same model.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 1

covercuts (integer): Cover cut generation ↵

Controls cover cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

crossover (integer): Barrier crossover strategy ↵

Determines the crossover strategy used to transform the interior solution produced by barrier or PDHG into a basic solution (note that crossover is not available for QP or QCP models). Crossover consists of three phases: (i) a primal push phase, where primal variables are pushed to bounds, (ii) a dual push phase, where dual variables are pushed to bounds, and (iii) a cleanup phase, where simplex is used to remove any primal or dual infeasibilities that remain after the push phases are complete. The order of the first two phases and the algorithm used for the third phase are both controlled by the crossover parameter:

For table, please visit Gurobi Documentation.

The default value of -1 chooses the strategy automatically. Use value 0 to disable crossover; this setting returns the interior solution computed by barrier or PDHG. Since an interior solution is typically less accurate than a basic solution after crossover, disabling crossover may sometimes result in barrier or PDHG performing more iterations to improve the returned interior solution.

Note: Barrier and PDHG only

See also Gurobi Documentation.

Default: -1

crossoverbasis (integer): Crossover initial basis construction strategy ↵

Determines the initial basis construction strategy for crossover. A value of 0 chooses an initial basis quickly. A value of 1 can take much longer, but often produces a more numerically stable start basis. The default value of -1 makes an automatic choice.

Note: Barrier and PDHG only

See also Gurobi Documentation.

Default: -1

cutaggpasses (integer): Constraint aggregation passes performed during cut generation ↵

A non-negative value indicates the maximum number of constraint aggregation passes performed during cut generation. Overrides the cuts parameter.

Changing the value of this parameter rarely produces a significant benefit.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

cutoff (real): Objective cutoff ↵

Indicates that you aren't interested in solutions whose objective values are worse than the specified value. If the objective value for the optimal solution is equal to or better than the specified cutoff, the solver will return the optimal solution. Otherwise, it will terminate with a Terminated by Solver status.

See also Gurobi Documentation.

Default: maxdouble

cutpasses (integer): Root cutting plane pass limit ↵

A non-negative value indicates the maximum number of cutting plane passes performed during root cut generation. The default value chooses the number of cut passes automatically.

In addition to cutting plane separation, each cut pass also applies heuristics and node probing and also may launch parallel root helper threads. So even when the cuts parameter is set to 0, the cut loop will apply probing, heuristics and parallel root helpers in a single cut loop iteration.

You should experiment with different values of this parameter if you notice the MIP solver spending significant time on root cut passes that have little impact on the objective bound.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

cuts (integer): Global cut generation control ↵

Global cut aggressiveness setting. Use value 0 to shut off cuts, 1 for moderate cut generation, 2 for aggressive cut generation, and 3 for very aggressive cut generation. The default -1 value chooses automatically. This parameter is overridden by the parameters that control individual cut types (e.g., cliquecuts).

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

degenmoves (integer): Degenerate simplex moves ↵

Limits degenerate simplex moves. These moves are performed to improve the integrality of the current relaxation solution. By default, the algorithm chooses the number of degenerate move passes to perform automatically.

The default setting generally works well, but there can be cases where an excessive amount of time is spent after the initial root relaxation has been solved but before the cut generation process or the root heuristics have started. If you see multiple ‘Total elapsed time' messages in the log immediately after the root relaxation log, you may want to try setting this parameter to 0.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

disconnected (integer): Disconnected component strategy ↵

A MIP or an LP model can sometimes be made up of multiple, completely independent sub-models. This parameter controls how aggressively Gurobi tries to exploit this structure. A value of 0 ignores this structure entirely, while larger values try more aggressive approaches. The default value of -1 chooses automatically.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

displayinterval (integer): Frequency at which log lines are printed ↵

Determines the frequency at which log lines are printed (in seconds).

See also Gurobi Documentation.

Default: 5

distributedmipjobs (integer): Enables the distributed MIP solver ↵

Enables distributed MIP. A value of n causes the MIP solver to divide the work of solving a MIP model among n machines. Use the ComputeServer parameter to indicate the name of the cluster where you would like your distributed MIP job to run (or use WorkerPool if your client machine will act as manager and you just need a pool of workers).

The distributed MIP solver produces a slightly different log from the standard MIP solver, and provides different callbacks as well. Please refer to the Distributed Algorithms section of the Gurobi Remote Services Reference Manual for additional details.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

.dofuncpieceerror (real): Error allowed for PWL translation of function constraints ↵

The default error behavior for piecewise-linear approximation of a function constraint is controlled by funcPieceError. This dot option .doFuncPieceError allows to overwrite the default behavior by constraint. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: 1e-3

.dofuncpiecelength (real): Piece length for PWL translation of function constraints ↵

The default length behavior for piecewise-linear approximation of a function constraint is controlled by funcPieceLength. This dot option .doFuncPieceError allows to overwrite the default behavior by constraint. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: 1e-2

.dofuncpieceratio (real): Control whether to under- or over-estimate function values in PWL approximation ↵

The default ratio behavior for piecewise-linear approximation of a function constraint is controlled by funcPieceRatio. This dot option .doFuncPieceError allows to overwrite the default behavior by constraint. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: -1

.dofuncpieces (integer): Sets strategy for PWL function approximation ↵

The default strategy for performing a piecewise-linear approximation of a function constraint is set by funcPieces. This dot option .doFuncPieces allows to overwrite the default strategy by constraint. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: 0

value	meaning
-2	Bounds the relative error of the approximation; the error bound is provided in the FuncPieceError parameter
-1	Bounds the absolute error of the approximation; the error bound is provided in the FuncPieceError parameter
0	Automatic based on relative error approach
1	Uses a fixed width for each piece; the actual width is provided in the FuncPieceLength parameter
>=2	Sets the number of pieces; pieces are equal width

dualimpliedcuts (integer): Dual implied bound cut generation ↵

Controls dual implied bound cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

dualreductions (boolean): Disables dual reductions in presolve ↵

Determines whether dual reductions are performed during the optimization process. You should disable these reductions if you received an optimization status of INF_OR_UNBD and would like a more definitive conclusion.

See also Gurobi Documentation.

Default: 1

dumpbcsol (string): Dump incumbents to GDX files during branch-and-cut ↵

The content of this string option is used as a file stem for GDX point files. The file name gets completed by the solution number. So if this option has beed set to mysol then GDX files containing the new solution with the names mysol0.gdx, mysol1.gdx, ... will be created. The number of GDX files created depends on the number of solutions Gurobi finds during branch-and-cut.

feasibilitytol (real): Primal feasibility tolerance ↵

All constraints must be satisfied to a tolerance of feasibilitytol. Tightening this tolerance can produce smaller constraint violations, but for numerically challenging models it can sometimes lead to much larger iteration counts.

See also Gurobi Documentation.

Range: [1e-09, 0.01]

Default: 1e-06

feasopt (boolean): Computes a minimum-cost relaxation to make an infeasible model feasible ↵

With Feasopt turned on, a minimum-cost relaxation of the right hand side values of constraints or bounds on variables is computed in order to make an infeasible model feasible. It marks the relaxed right hand side values and bounds in the solution listing.

Several options are available for the metric used to determine what constitutes a minimum-cost relaxation which can be set by option FeasOptMode.

Feasible relaxations are available for all problem types.

Default: 0

value	meaning
0	Turns Feasible Relaxation off
1	Turns Feasible Relaxation on

feasoptmode (integer): Mode of FeasOpt ↵

The parameter FeasOptMode allows different strategies in finding feasible relaxation in one or two phases. In its first phase, it attempts to minimize its relaxation of the infeasible model. That is, it attempts to find a feasible solution that requires minimal change. In its second phase, it finds an optimal solution (using the original objective) among those that require only as much relaxation as it found necessary in the first phase. Values of the parameter FeasOptMode indicate two aspects: (1) whether to stop in phase one or continue to phase two and (2) how to measure the minimality of the relaxation (as a sum of required relaxations; as the number of constraints and bounds required to be relaxed; as a sum of the squares of required relaxations).

Default: 0

value	meaning
0	Minimize sum of relaxations Minimize the sum of all required relaxations in first phase only
1	Minimize sum of relaxations and optimize Minimize the sum of all required relaxations in first phase and execute second phase to find optimum among minimal relaxations
2	Minimize number of relaxations Minimize the number of constraints and bounds requiring relaxation in first phase only
3	Minimize number of relaxations and optimize Minimize the number of constraints and bounds requiring relaxation in first phase and execute second phase to find optimum among minimal relaxations
4	Minimize sum of squares of relaxations Minimize the sum of squares of required relaxations in first phase only
5	Minimize sum of squares of relaxations and optimize Minimize the sum of squares of required relaxations in first phase and execute second phase to find optimum among minimal relaxations

.feaspref (real): feasibility preference ↵

You can express the costs associated with relaxing a bound or right hand side value during a FeasOpt run through the .feaspref option. The syntax for dot options is explained in the Introduction chapter of the Solver Manual. The input value denotes the users willingness to relax a constraint or bound. More precisely, the reciprocal of the specified value is used to weight the relaxation of that constraint or bound. The user may specify a preference value less than or equal to 0 (zero), which denotes that the corresponding constraint or bound must not be relaxed.

Default: 1

feasrelaxbigm (real): Big-M value for feasibility relaxations ↵

When relaxing a constraint in a feasibility relaxation, it is sometimes necessary to introduce a big-M value. This parameter determines the default magnitude of that value.

For details about feasibility relaxations, refer to e.g. GRBfeasrelax in the C API.

See also Gurobi Documentation.

Default: 1e+06

fixoptfile (string): Option file for fixed problem optimization ↵

fixvarsinindicators (boolean): Controls conversion of indicator constraints in the fixed model ↵

Controls how Gurobi deals with indicator constraints when creating the fixed model (e.g. GRBconverttofixed and GRBfixmodel in C, or Model.convertToFixed and Model.fixed in Python).

If set to 0 (the default), then an indicator constraint is discarded if its premise is false (i.e., if the associated binary indicator variable is fixed to a value that does not satisfy the premise condition) in the solution or MIP start that is associated to the fixed model. On the other hand, if the premise of the indicator is true, then the implied linear constraint is added as a regular linear constraint to the fixed model.

Let's consider the case where fixvarsinindicators is set to 0. If there is an indicator constraint

\(z = 0 \rightarrow ax \leq b\)

in the model and variable \(z\) has value 1 in the solution for which the fixed model is created, then the indicator constraint is not active and it is therefore discarded from the fixed model. If the indicator variable \(z\) has value 0, then the indicator is active and the linear constraint \(ax \leq b\) is added to the fixed model.

If the fixvarsinindicators parameter is set to 1, then all variables (including continuous variables) in the indicator constraint are fixed to their solution value, independent of whether the indicator is active or not in the associated solution.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

flowcovercuts (integer): Flow cover cut generation ↵

Controls flow cover cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

flowpathcuts (integer): Flow path cut generation ↵

Controls flow path cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

freegamsmodel (boolean): Preserves memory by dumping the GAMS model instance representation temporarily to disk ↵

In order to provide the maximum amount of memory to the solver this option dumps the internal representation of the model instance temporarily to disk and frees memory. This option only works with SolveLink=0 and only for models without quadratic constraints.

Default: 0

funcmaxval (real): Maximum value for x and y variables in function constraints ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

Very large values in piecewise-linear approximations can cause numerical issues. This parameter limits the bounds on the variables that participate in function constraints approximated by a piecewise-linear function. Specifically, any bound larger than FuncMaxVal (in absolute value) on the variables participating in such a function constraint will be truncated.

If the FuncNonlinear attribute of the constraint is set to 1, or if it is set to −1 and the global FuncNonlinear parameter is set to 1, the function constraint is not approximated by a piecewise-linear function and the FuncMaxVal parameter does not apply.

See also Gurobi Documentation.

Default: 1e+06

funcnonlinear (boolean): Chooses the approximation approach used to handle function constraints ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

This parameter controls whether general function constraints with their FuncNonlinear attribute set to -1 are replaced with a static piecewise-linear approximation (0), or handled inside the branch-and-bound tree using a dynamic outer-approximation approach (1).

See the discussion of function constraints for more information.

See also Gurobi Documentation.

Default: 1

funcpieceerror (real): Error allowed for PWL translation of function constraint ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

If the funcpieces parameter is set to value \(-1\) or \(-2\), this attribute provides the maximum allowed error (absolute for \(-1\), relative for \(-2\)) in the piecewise-linear approximation.

See also Gurobi Documentation.

Default: 0.001

funcpiecelength (real): Piece length for PWL translation of function constraint ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

If the funcpieces parameter is set to value \(1\), this parameter gives the length of each piece of the piecewise-linear approximation.

See also Gurobi Documentation.

Default: 0.01

funcpieceratio (real): Controls whether to under- or over-estimate function values in PWL approximation ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

This parameter controls whether the piecewise-linear approximation of a function constraint is an underestimate of the function, an overestimate, or somewhere in between. A value of \(0.0\) will always underestimate, while a value of \(1.0\) will always overestimate. A value in between will interpolate between the underestimate and the overestimate. A special value of -1 chooses points that are on the original function. The behaviour is not defined for other negative values.

See the discussion of function constraints for more information.

See also Gurobi Documentation.

Default: -1

funcpieces (integer): Sets strategy for PWL function approximation ↵

Deprecated since version 13.0: Using function constraints is deprecated since version 13.0. Please use nonlinear constraints instead.

This parameter sets the strategy used for performing a piecewise-linear approximation of a function constraint. There are a few options:

• FuncPieces >= 2: Sets the number of pieces; pieces are equal width.
• FuncPieces = 1: Uses a fixed width for each piece; the actual width is provided in the funcpiecelength parameter.
• FuncPieces = 0: Default value; chooses automatically. Currently it uses the relative error approach for the approximation, while for version 10.0 or earlier it mainly uses the number of function constraints to set the total number of pieces.
• FuncPieces = -1: Bounds the absolute error of the approximation; the error bound is provided in the funcpieceerror parameter.
• FuncPieces = -2: Bounds the relative error of the approximation; the error bound is provided in the funcpieceerror parameter.

This parameter only applies to function constraints whose funcpieces attribute has been set to \(0\).

See the discussion of function constraints for more information.

See also Gurobi Documentation.

Default: 0

value	meaning
-2	Bounds the relative error of the approximation; the error bound is provided in the FuncPieceError parameter
-1	Bounds the absolute error of the approximation; the error bound is provided in the FuncPieceError parameter
0	Automatic PWL approximation
1	Uses a fixed width for each piece; the actual width is provided in the FuncPieceLength parameter
>=2	Sets the number of pieces; pieces are equal width

gomorypasses (integer): Root Gomory cut pass limit ↵

A non-negative value indicates the maximum number of Gomory cut passes performed. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

gubcovercuts (integer): GUB cover cut generation ↵

Controls GUB cover cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

heuristics (real): Turn MIP heuristics up or down ↵

Determines the amount of time spent in MIP heuristics. You can think of the value as the desired fraction of total MIP runtime devoted to heuristics (so by default, Gurobi aims to spend 5% of runtime on heuristics). Larger values produce more and better feasible solutions, at a cost of slower progress in the best bound.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Range: [0, 1]

Default: 0.05

iis (integer): Run the Irreducible Inconsistent Subsystem (IIS) finder if the problem is infeasible ↵

Default: 0

value	meaning
0	No conflict analysis
1	Conflict analysis after solve if infeasible
2	Conflict analysis without previous solve

iismethod (integer): IIS method ↵

Chooses the IIS method to use. To compute an IIS for an LP, it is sufficient to solve an LP with dimensions similar to the dual of the original model. If the solve time for that LP is excessive, setting the IISMethod parameter to 1 may offer a faster alternative; other settings do not alter the default approach for infeasible LPs. For MIPs, filtering of constraints and variables is required, which involves solving a series of related MIP subproblems. Methods 0-2 all use filtering techniques. Method 0 is often faster than method 1, but may produce a larger IIS. Method 2 ignores the bound constraints. It therefore tends to be faster than methods 0-1, but will fail if these bounds are necessary to make the problem infeasible. Method 3 will return the IIS for the LP relaxation of a MIP model if the relaxation is infeasible, even though the result may not be minimal when integrality constraints are included. The default value of -1 chooses automatically.

See also Gurobi Documentation.

Default: -1

impliedcuts (integer): Implied bound cut generation ↵

Controls implied bound cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

improvestartgap (real): Trigger solution improvement ↵

The MIP solver can change parameter settings in the middle of the search in order to adopt a strategy that gives up on moving the best bound and instead devotes all of its effort towards finding better feasible solutions. This parameter allows you to specify an optimality gap at which the MIP solver switches to this solution improvement strategy. For example, setting this parameter to 0.1 will cause the MIP solver to switch strategies once the relative optimality gap is smaller than 0.1.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

improvestartnodes (real): Trigger solution improvement ↵

The MIP solver can change parameter settings in the middle of the search in order to adopt a strategy that gives up on moving the best bound and instead devotes all of its effort towards finding better feasible solutions. This parameter allows you to specify the node count at which the MIP solver switches to this solution improvement strategy. For example, setting this parameter to 10 will cause the MIP solver to switch strategies once the node count is larger than 10, provided that at least one feasible solution has been found. If no incumbent solution exists when the specified node count is reached, the strategy switch will occur as soon as the first feasible solution is discovered.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

improvestarttime (real): Trigger solution improvement ↵

The MIP solver can change parameter settings in the middle of the search in order to adopt a strategy that gives up on moving the best bound and instead devotes all of its effort towards finding better feasible solutions. This parameter allows you to specify the time (in seconds) when the MIP solver switches to this solution improvement strategy. For example, setting this parameter to 10 will cause the MIP solver to switch strategies 10 seconds after starting the optimization, provided that at least one feasible solution has been found. If no incumbent solution exists when the specified time is reached, the strategy switch will occur as soon as the first feasible solution is discovered.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

improvestartwork (real): Trigger solution improvement ↵

The MIP solver can change parameter settings in the middle of the search in order to adopt a strategy that gives up on moving the best bound and instead devotes all of its effort towards finding better feasible solutions. This parameter allows you to specify the work (in work units) when the MIP solver switches to this solution improvement strategy. For example, setting this parameter to 10 will cause the MIP solver to switch strategies 10 work units after starting the optimization, provided that at least one feasible solution has been found. If no incumbent solution exists when the specified work is reached, the strategy switch will occur as soon as the first feasible solution is discovered.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

infproofcuts (integer): Infeasibility proof cut generation ↵

Controls infeasibility proof cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

integralityfocus (boolean): Set the integrality focus ↵

One unfortunate reality in MIP is that integer variables don't always take exact integral values. While this typically doesn't create significant problems, in some situations the side-effects can be quite undesirable. The best-known example is probably a trickle flow, where a continuous variable that is meant to be zero when an associated binary variable is zero instead takes a non-trivial value. More precisely, given a constraint \(y \leq M b\), where \(y\) is a non-negative continuous variable, \(b\) is a binary variable, and \(M\) is a constant that captures the largest possible value of \(y\), the constraint is intended to enforce the relationship that \(y\) must be zero if \(b\) is zero. With the default integer feasibility tolerance, the binary variable is allowed to take a value as large as \(1e-5\) while still being considered as taking value zero. If the \(M\) value is large, then the \(M b\) upper bound on the \(y\) variable can be substantial.

Reducing the value of the intfeastol parameter can mitigate the effects of such trickle flows, but often at a significant cost, and often with limited success. The integralityfocus parameter provides a better alternative. Setting this parameter to 1 requests that the solver work harder to try to avoid solutions that exploit integrality tolerances. More precisely, the solver tries to find solutions that are still (nearly) feasible if all integer variables are rounded to exact integral values. Gurobi says that the solver won't always succeed in finding such solutions, and that this setting introduces a modest performance penalty, but the setting will significantly reduce the frequency and magnitude of such violations.

See also Gurobi Documentation.

Default: 0

intfeastol (real): Integer feasibility tolerance ↵

An integrality restriction on a variable is considered satisfied when the variable's value is less than intfeastol from the nearest integer value. Tightening this tolerance can produce smaller integrality violations, but very tight tolerances may significantly increase runtime. Loosening this tolerance rarely reduces runtime.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Range: [1e-09, 0.1]

Default: 1e-05

iterationlimit (real): Simplex iteration limit ↵

Limits the number of simplex iterations performed. The limit applies to MIP, barrier crossover, and simplex. Optimization returns with an Iteration Interrupt status if the limit is exceeded.

See also Gurobi Documentation.

Default: infinity

kappa (boolean): Display approximate condition number estimates for the optimal simplex basis ↵

Default: 0

value	meaning
0	Do not compute and display approximate condition number
1	Compute and display approximate condition number

kappaexact (boolean): Display exact condition number estimates for the optimal simplex basis ↵

Default: 0

value	meaning
0	Do not compute and display exact condition number
1	Compute and display exact condition number

.lazy (integer): Lazy constraints value ↵

Determines whether a linear constraint is treated as a lazy constraint. At the beginning of the MIP solution process, any constraint whose Lazy attribute is set to 1, 2, or 3 (the default value is 0) is removed from the model and placed in the lazy constraint pool. Lazy constraints remain inactive until a feasible solution is found, at which point the solution is checked against the lazy constraint pool. If the solution violates any lazy constraint, the solution is discarded and one or more of the violated lazy constraints are pulled into the active model.

Larger values for this attribute cause the constraint to be pulled into the model more aggressively. With a value of 1, the constraint can be used to cut off a feasible solution, but it won't necessarily be pulled in if another lazy constraint also cuts off the solution. With a value of 2, all lazy constraints that are violated by a feasible solution will be pulled into the model. With a value of 3, lazy constraints that cut off the relaxation solution are also pulled in.

Any constraint whose Lazy attribute is set to -1 is treated as a user cut; it is removed from the model and placed in the user cut pool. User cuts may be added to the model at any node in the branch-and-cut search tree to cut off relaxation solutions.

The main difference between user cuts and lazy constraints is that the former are not allowed to cut off integer-feasible solutions. In other words, they are redundant for the MIP model, and the solver is free to decide whether or not to use them to cut off relaxation solutions. The hope is that adding them speeds up the overall solution process. Lazy constraints have no such restrictions. They are essential to the model, and the solver is forced to apply them whenever a solution would otherwise not satisfy them.

Only affects MIP models. Lazy constraints are only active if option LazyConstraints is enabled and are specified through the option .lazy. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: 0

lazyconstraints (boolean): Indicator to use lazy constraints ↵

Default: 0

liftprojectcuts (integer): Lift-and-project cut generation ↵

Controls lift-and-project cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

lpwarmstart (integer): Warm start usage in simplex ↵

Controls whether and how Gurobi uses warm start information for an LP optimization. A warm start can consist of any combination of basis statuses, a primal start vector, or a dual start vector. It is specified using the attributes VBasis and CBasis or PStart and DStart on the original model.

Setting this parameter to 2 is particularly useful for communicating advanced start information while retaining the performance benefits of presolve. The default value of -1 is equivalent to 1 for all method choices except for PDHG, for which it is equivalent to 2.

As a general rule, setting this parameter to 0 ignores any start information and solves the model from scratch. Setting it to 1 (the default) uses the provided warm start information to solve the original, unpresolved problem, regardless of whether presolve is enabled. Setting it to 2 uses the start information to solve the presolved problem, assuming that presolve is enabled. This involves mapping the solution of the original problem into an equivalent (or sometimes nearly equivalent) crushed solution of the presolved problem. If presolve is disabled, then setting 2 still prioritizes start vectors, while setting 1 prioritizes basis statuses. Taken together, the LPWarmStart parameter setting, the LP algorithm specified by Gurobi's Method parameter, and the available advanced start information determine whether Gurobi will use basis statuses only, basis statuses augmented with information from start vectors, or a basis obtained by applying the crossover method to the provided primal and dual start vectors to jump start the optimization.

When Gurobi's Method parameter requests the barrier solver, primal and dual start vectors are prioritized over basis statuses (but only if you provide both). These start vectors are fed to the crossover procedure. This is the same crossover that is used to compute a basic solution from the interior solution produced by the core barrier algorithm, but in this case crossover is started from arbitrary start vectors. If you set the LPWarmStart parameter to 1, crossover will be invoked on the original model using the provided vectors. Any provided basis information will not be used in this case. If you set LPWarmStart to 2, crossover will be invoked on the presolved model using crushed start vectors. If you set the parameter to 2 and provide a basis but no start vectors, the basis will be used to compute the corresponding primal and dual solutions on the original model. Those solutions will then be crushed and used as primal and dual start vectors for the crossover, which will then construct a basis for the presolved model. Note that for all of these settings and start combinations, no barrier algorithm iterations are performed.

When the Method parameter selects PDHG, primal and dual start vectors are used to warm start PDHG iterations directly before proceeding to crossover if it is enabled. If a warm start basis is provided, it will be used to construct start vectors for the PDHG solve. If both a basis and vectors are given, vectors are prioritised over basis statuses. If you set LPWarmStart to 1, start vectors will be used to warm-start PDHG on the original model. Otherwise, if presolve is enabled, start vectors will be crushed and used to warm-start PDHG on the presolved model.

The simplex algorithms provide more warm-starting options. With a parameter value of 1, simplex will start from a provided basis, if available. Otherwise, it uses a provided start vector to refine the crash basis it computes. Primal simplex will use PStart and dual simplex will use DStart in this refinement process.

With a value of 2, simplex will use the crushed start vector on the presolved model (PStart for primal simplex, DStart for dual) to refine the crash basis. This is true regardless of whether the start is derived from start vectors or a starting basis from the original model. The difference is that if you provide an advanced basis, the basis will be used to compute the corresponding primal and dual solutions on the original model from which the primal or dual start on the presolved model will be derived.

Note: Only affects linear programming (LP) models

See also Gurobi Documentation.

Default: -1

markowitztol (real): Threshold pivoting tolerance ↵

The Markowitz tolerance is used to limit numerical error in the simplex algorithm. Specifically, larger values reduce the error introduced in the simplex basis factorization. A larger value may avoid numerical problems in rare situations, but it will also harm performance.

See also Gurobi Documentation.

Range: [0.0001, 0.999]

Default: 0.0078125

masterknapsackcuts (integer): Master Knapsack Polytope cut generation ↵

Controls the generation of cuts derived from the master knapsack polytope. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

See also Gurobi Documentation.

Default: -1

memlimit (real): Memory limit ↵

Limits the total amount of memory (in GB, i.e., \(10^9\) bytes) available to Gurobi. If more is needed, Gurobi will fail with an Solver error.

Note that it is not possible to retrieve solution information after an error termination. Thus, the behavior of this parameter is different from that of other termination criteria like softmemlimit, timelimit, or nodelimit, where the solver will terminate with a Status Code and solution information will still be available.

One advantage of using this parameter rather than the similar softmemlimit is that memlimit is checked after every memory allocation, so Gurobi will terminate at precisely the point where the limit is exceeded.

Note that allocated memory is tracked across all models within a Gurobi environment. If you create multiple models in one environment, these additional models will count towards overall memory consumption.

Memory usage is also tracked across all threads. One consequence of this is that termination may be non-deterministic for multi-threaded runs.

See also Gurobi Documentation.

Default: maxdouble

method (integer): Define method, e.g., Simplex, to solve continuous models ↵

Synonyms: lpmethod rootmethod

Algorithm used to solve continuous models or the initial root relaxation of a MIP model.

Available settings and default behaviour depend on the model type or the type of the initial root relaxation. In the current release, the default Automatic (Method=-1) setting will typically choose non-deterministic concurrent (Method=3) for an LP, barrier (Method=2) for a QP or QCP, and dual (Method=1) for the MIP root relaxation. If the size of the MIP root relaxation is large, then it will often select deterministic concurrent (Method=4) or deterministic concurrent simplex (Method=5).

Concurrent methods aren't available for QP and QCP. Only the simplex and barrier algorithms are available for continuous QP models. If you select barrier (Method=2) to solve the root of an MIQP model, then you need to also select barrier for the node relaxations (i.e. set NodeMethod=2). Only barrier is available for continuous QCP models. However if you choose LP relaxations for solving MIQCP, you can also select the simplex algorithms (Method=0 or Method=1).

Concurrent optimizers run multiple solvers on multiple threads simultaneously and choose the one that finishes first. The solvers that are run concurrently can be controlled with the concurrentmethod parameter. The deterministic options (Method=4 and Method=5) give the exact same result each time, while the non-deterministic option (Method=3) is often faster but can produce different optimal bases when run multiple times.

The default setting is rarely significantly slower than the best possible setting, so you generally won't see a big gain from changing this parameter. There are classes of models where one particular algorithm is consistently fastest, though, so you may want to experiment with different options when confronted with a particularly difficult model.

Note that if memory is tight on an LP model, you should consider using the dual simplex method (Method=1). The concurrent optimizer, which is typically chosen when using the default setting, consumes a lot more memory than dual simplex alone.

In multi-objective LP optimization:

• The first objective is solved using LP defaults. It can be set by the user using the Method parameter.
• Subsequent objectives are solved by default using primal simplex to allow for warm starting. The algorithm used here can be controlled using multiobjmethod.

See also Gurobi Documentation.

Default: -1

value	meaning
-1	automatic
0	primal simplex
1	dual simplex
2	barrier
3	concurrent
4	deterministic concurrent
5	deterministic concurrent simplex (deprecated; see concurrentmethod)
6	PDHG (Primal-Dual Hybrid Gradient)

minrelnodes (integer): Minimum relaxation heuristic control ↵

Number of nodes to explore in the minimum relaxation heuristic.

This heuristic is quite expensive, and generally produces poor quality solutions. You should generally only use it if other means, including exploration of the tree with default settings, fail to produce a feasible solution.

The default value automatically chooses whether to apply the heuristic. It will only rarely choose to do so.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

mipfocus (integer): Set the focus of the MIP solver ↵

The mipfocus parameter allows you to modify your high- level solution strategy, depending on your goals. By default, the Gurobi MIP solver strikes a balance between finding new feasible solutions and proving that the current solution is optimal. If you are more interested in finding feasible solutions quickly, you can select MIPFocus=1. If you believe the solver is having no trouble finding good quality solutions, and wish to focus more attention on proving optimality, select MIPFocus=2. If the best objective bound is moving very slowly (or not at all), you may want to try MIPFocus=3 to focus on the bound.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

mipgap (real): Relative MIP optimality gap ↵

The MIP solver will terminate (with an optimal result) when the gap between the lower and upper objective bound is less than mipgap times the absolute value of the incumbent objective value. More precisely, if \(z_P\) is the primal objective bound (i.e., the incumbent objective value, which is the upper bound for minimization problems), and \(z_D\) is the dual objective bound (i.e., the lower bound for minimization problems), then the MIP gap is defined as

\(gap = \vert z_P - z_D\vert / \vert z_P\vert\).

Note that if \(z_P = z_D = 0\), then the gap is defined to be zero. If \(z_P = 0\) and \(z_D \neq 0\), the gap is defined to be infinity.

For most models, \(z_P\) and \(z_D\) will have the same sign throughout the optimization process, and then the gap is monotonically decreasing. But if \(z_P\) and \(z_D\) have opposite signs, the relative gap may increase after finding a new incumbent solution, even though the absolute gap \(\vert z_P - z_D\vert\) has decreased.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Range: [0, ∞]

Default: GAMS optcr

mipgapabs (real): Absolute MIP optimality gap ↵

The MIP solver will terminate (with an optimal result) when the gap between the lower and upper objective bound is less than mipgapabs.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Range: [0, ∞]

Default: GAMS optca

mipsepcuts (integer): MIP separation cut generation ↵

Controls MIP separation cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

mipstart (boolean): Use mip starting values ↵

Default: 0

value	meaning
0	Do not use the values
1	Use the values

mipstopexpr (string): Stop expression for branch and bound ↵

If the provided logical expression is true, the branch-and-bound is aborted. Supported values are: resusd, nodusd, objest, objval, is_feasible. Supported opertators are: +, -, *, /, ^, %, !=, ==, <, <=, >, >=, !, &&, ||, (, ), abs, ceil, exp, floor, log, log10, pow, sqrt. Example:

nodusd >= 1000 && is_feasible && abs(objest - objval) / abs(objval) < 0.1

If multiple stop expressions are given in an option file, the algorithm stops if any of them is true (|| concatenation).

miptrace (string): Filename of MIP trace file ↵

More info is available in chapter Solve trace.

miptracenode (integer): Node interval when a trace record is written ↵

Default: 100

miptracetime (real): Time interval when a trace record is written ↵

Default: 1

miqcpmethod (integer): Method used to solve MIQCP models ↵

Controls the method used to solve MIQCP models. Value 1 uses a linearized, outer-approximation approach, while value 0 solves continuous QCP relaxations at each node. The default setting (-1) chooses automatically.

Note: Only affects MIQCP models

See also Gurobi Documentation.

Default: -1

mircuts (integer): MIR cut generation ↵

Controls Mixed Integer Rounding (MIR) cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

mixingcuts (integer): Mixing cut generation ↵

Controls Mixing cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

modkcuts (integer): Mod-k cut generation ↵

Controls mod-k cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

multimipstart (string): Use multiple (partial) mipstarts provided via gdx files ↵

Specifies (multiple) GDX files with values for the variables. Each file is treated as one intial guess for the MIP start. These MIP starts are added in addition to the initial guess provided by the level attribute. A MIP start GDX file can be created, for example, by using the command line option savepoint.

This option further allows to add partial MIP starts where some variable level records are not given. GUROBI will then try to construct a full MIP start out of it. In order to not provide a certain variable level record, simply not include that record in the GDX file or set the level value to NA or UNDEF.

This option requires mipstart enabled.

multiobjmethod (integer): Warm-start method to solve for subsequent objectives ↵

When solving a continuous multi-objective model using a hierarchical approach, the model is solved once for each objective. The algorithm used to solve for the highest priority objective is controlled by the method parameter. This parameter determines the algorithm used to solve for subsequent objectives. As with the method parameters, values of 0 and 1 use primal and dual simplex, respectively. A value of 2 indicates that warm- start information from previous solves should be discarded, and the model should be solved from scratch (using the algorithm indicated by the method parameter). The default setting of -1 usually chooses primal simplex.

Note: Only affects continuous multi-objective models

See also Gurobi Documentation.

Default: -1

multiobjpre (integer): Initial presolve on multi-objective models ↵

Controls the initial presolve level used for multi-objective models. Value 0 disables the initial presolve, value 1 applies presolve conservatively, and value 2 applies presolve aggressively. The default -1 value usually applies presolve conservatively. Aggressive presolve may increase the chance of the objective values being slightly different than those for other options.

Note: Only affects multi-objective models

See also Gurobi Documentation.

Default: -1

multobj (boolean): Controls the hierarchical optimization of multiple objectives ↵

Default: 0

names (boolean): Indicator for loading names ↵

Default: 1

value	meaning
0	Do not load GAMS names into Gurobi model
1	Load GAMS names into Gurobi model

networkalg (integer): Network simplex algorithm ↵

Controls whether to use network simplex. Value 0 doesn't use network simplex. Value 1 indicates to use network simplex, if an LP is a network problem. The default -1 value chooses automatically.

Note: Only affects linear programming (LP) models

See also Gurobi Documentation.

Default: -1

networkcuts (integer): Network cut generation ↵

Controls network cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

nlbarcfeastol (real): NL barrier complementarity tolerance ↵

Important: Gurobi considers this feature a preview in this release. This means that it is fully tested and supported, but will likely undergo significant changes in subsequent Gurobi technical or major releases, potentially including breaking changes in API, behavior and packaging.

For the NL barrier algorithm, the complementarity error must be smaller than nlbarcfeastol in order for a model to be declared locally optimal. Due to problem transformations like presolve or internal scaling, the returned solution's residuals may deviate from those observed by the algorithm.

Note: Only affects the NL barrier algorithm

See also Gurobi Documentation.

Default: 1e-08

nlbardfeastol (real): NL barrier dual feasibility tolerance ↵

Important: Gurobi considers this feature a preview in this release. This means that it is fully tested and supported, but will likely undergo significant changes in subsequent Gurobi technical or major releases, potentially including breaking changes in API, behavior and packaging.

For the NL barrier algorithm, the dual feasibility error must be smaller than nlbardfeastol in order for a model to be declared locally optimal. Due to problem transformations like presolve or internal scaling, the returned solution's residuals may deviate from those observed by the algorithm.

Note: Only affects the NL barrier algorithm

See also Gurobi Documentation.

Default: 1e-06

nlbariterlimit (integer): NL barrier iteration limit ↵

Important: Gurobi considers this feature a preview in this release. This means that it is fully tested and supported, but will likely undergo significant changes in subsequent Gurobi technical or major releases, potentially including breaking changes in API, behavior and packaging.

Limits the number of barrier NL iterations performed.

Optimization returns with an Iteration Interrupt status if the limit is exceeded.

Note: Only affects the NL barrier algorithm

See also Gurobi Documentation.

Default: 1000

nlbarpfeastol (real): NL barrier primal feasibility tolerance ↵

Important: Gurobi considers this feature a preview in this release. This means that it is fully tested and supported, but will likely undergo significant changes in subsequent Gurobi technical or major releases, potentially including breaking changes in API, behavior and packaging.

For the NL barrier algorithm, the primal feasibility error must be smaller than nlbarpfeastol in order for a model to be declared locally optimal. Due to problem transformations like presolve or internal scaling, the returned solution's residuals may deviate from those observed by the algorithm.

Note: Only affects the NL barrier algorithm

See also Gurobi Documentation.

Default: 1e-06

nlpheur (integer): Controls the NLP heuristic for non-convex quadratic models ↵

The NLP heuristic uses a non-linear barrier solver to find feasible solutions to nonconvex quadratic and nonlinear models during a global optimization solve. It often helps to find solutions quicker, but in some cases it can consume significant runtime without producing a solution. A value of 0 disables the heuristic completely, while larger values call the heuristic more and more aggressively during the optimization process. The default -1 value chooses automatically.

Note: Only affects models with nonconvex quadratic or nonlinear expressions in the objective or constraints

See also Gurobi Documentation.

Default: -1

nodefiledir (string): Directory for MIP node files ↵

Determines the directory into which nodes are written when node memory usage exceeds the specified nodefilestart value.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: .

nodefilestart (real): Memory threshold for writing MIP tree nodes to disk ↵

If you find that the Gurobi Optimizer exhausts memory when solving a MIP, you should modify the NodefileStart parameter. When the amount of memory used to store nodes (measured in GB, i.e., \(10^9\) bytes) exceeds the specified parameter value, nodes are compressed and written to disk. Gurobi recommends a setting of 0.5, but you may wish to choose a different value, depending on the memory available in your machine. By default, nodes are written to the current working directory. The nodefiledir parameter can be used to choose a different location.

If you still exhaust memory after setting the NodefileStart parameter to a small value, you should try limiting the thread count. Each thread in parallel MIP requires a copy of the model, as well as several other large data structures. Reducing the threads parameter can sometimes significantly reduce memory usage.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

nodelimit (real): MIP node limit ↵

Limits the number of MIP nodes explored. Optimization returns with an Resource Interrupt status if the limit is exceeded. Note that if multiple threads are used for the optimization, the actual number of explored nodes may be slightly larger than the set limit.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

nodemethod (integer): Method used to solve MIP node relaxations ↵

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

value	meaning
-1	automatic
0	primal simplex
1	dual simplex
2	barrier

nonconvex (integer): Control how to deal with non-convex quadratic programs ↵

Sets the strategy for handling non-convex quadratic objectives or non-convex quadratic constraints. With setting 0, an error is reported if the original user model contains non-convex quadratic constructs (unless Q matrix linearization, as controlled by the preqlinearize parameter, removes the non-convexity). With setting 1, an error is reported if non-convex quadratic constructs could not be discarded or linearized during presolve. With setting 2, non-convex quadratic problems are solved by translating them into bilinear form and applying spatial branching. The default -1 setting is currently almost equivalent to 2, except that it takes less care to avoid presolve reductions that might transform a convex constraint into one that can no longer be detected to be convex, and thus can sometimes perform more presolve reductions.

Note: Only affects QP, QCP, MIQP, and MIQCP models

See also Gurobi Documentation.

Default: -1

norelheursolutions (integer): Limits the number of solutions found by the NoRel heuristic ↵

Default: 0

norelheurtime (real): Limits the amount of time (in seconds) spent in the NoRel heuristic ↵

Limits the amount of time (in seconds) spent in the NoRel heuristic. This heuristic searches for high-quality feasible solutions before solving the root relaxation. It can be quite useful on models where the root relaxation is particularly expensive.

Note that this parameter will introduce non-determinism - different runs may take different paths. Use the norelheurwork parameter for deterministic results.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

norelheurwork (real): Limits the amount of work performed by the NoRel heuristic ↵

Limits the amount of work spent in the NoRel heuristic. This heuristic searches for high-quality feasible solutions before solving the root relaxation. It can be quite useful on models where the root relaxation is particularly expensive.

The work metric used in this parameter is tough to define precisely. A single unit corresponds to roughly a second, but this will depend on the machine, the core count, and in some cases the model. You may need to experiment to find a good setting for your model.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

normadjust (integer): Simplex pricing norm ↵

Chooses from among multiple pricing norm variants. The details of how this parameter affects the simplex pricing algorithm are subtle and difficult to describe, so Gurobi has simply labeled the options 0 through 3. The default value of -1 chooses automatically.

Changing the value of this parameter rarely produces a significant benefit.

See also Gurobi Documentation.

Default: -1

numericfocus (integer): Set the numerical focus ↵

The numericfocus parameter controls the degree to which the code attempts to detect and manage numerical issues. The default setting (0) makes an automatic choice, with a slight preference for speed. Settings 1-3 increasingly shift the focus towards being more careful in numerical computations. With higher values, the code will spend more time checking the numerical accuracy of intermediate results, and it will employ more expensive techniques in order to avoid potential numerical issues.

See also Gurobi Documentation.

Default: 0

obbt (integer): Controls aggressiveness of optimality-based bound tightening ↵

Value 0 disables optimality-based bound tightening (OBBT). Levels 1-3 describe the amount of work allowed for OBBT ranging from moderate to aggressive. The default -1 value is an automatic setting which chooses a rather moderate setting.

See also Gurobi Documentation.

Default: -1

objnabstol (string): Allowable absolute degradation for objective ↵

This parameter is used to set the allowable degradation for an objective when doing hierarchical multi-objective optimization (MultObj). The syntax for this parameter is ObjNAbsTol ObjVarName value.

Hierarchical multi-objective optimization will optimize for the different objectives in the model one at a time, in priority order. If it achieves objective value z when it optimizes for this objective, then subsequent steps are allowed to degrade this value by at most ObjNAbsTol.

objnreltol (string): Allowable relative degradation for objective ↵

This parameter is used to set the allowable degradation for an objective when doing hierarchical multi-objective optimization (MultObj). The syntax for this parameter is ObjNRelTol ObjVarName value.

Hierarchical multi-objective optimization will optimize for the different objectives in the model one at a time, in priority order. If it achieves objective value z when it optimizes for this objective, then subsequent steps are allowed to degrade this value by at most ObjNRelTol*|z|.

objscale (real): Objective scaling ↵

When positive, divides the model objective by the specified value to avoid numerical issues that may result from very large or very small objective coefficients. The default value of 0 decides on the scaling automatically. A value less than zero uses the maximum coefficient to the specified power as the scaling, e.g., ObjScale=-1 would divide by the largest objective coefficient, while ObjScale=-0.5 would divide by the square root of that coefficient.

Note that objective scaling can lead to large dual violations on the original, unscaled objective when the optimality tolerance with the scaled objective is barely satisfied, so it should be used sparingly. Note also that scaling will be more effective when all objective coefficients are of similar orders of magnitude, as opposed to objectives with a wide range of coefficients. In the latter case, consider using the Multiple Objectives feature instead.

See also Gurobi Documentation.

Range: [-1, ∞]

Default: 0

optimalitytarget (integer): Controls the strategy to solve continuous nonlinear nonconvex models ↵

Default: -1

optimalitytol (real): Dual feasibility tolerance ↵

For the simplex algorithm and crossover, reduced costs must all be smaller than optimalitytol in the improving direction in order for a model to be declared optimal.

See also Gurobi Documentation.

Range: [1e-09, 0.01]

Default: 1e-06

.partition (integer): Variable partition value ↵

The MIP solver can perform a solution improvement heuristic using user-provided partition information. The provided partition number can be positive, which indicates that the variable should be included when the correspondingly numbered sub-MIP is solved, 0 which indicates that the variable should be included in every sub-MIP, or -1 which indicates that the variable should not be included in any sub-MIP. Variables that are not included in the sub-MIP are fixed to their values in the current incumbent solution.

To give an example, imagine you are solving a model with 400 variables and you set the partition attribute to -1 for variables 0-99, 0 for variables 100-199, 1 for variables 200-299, and 2 for variables 300-399. The heuristic would solve two sub-MIP models: sub-MIP 1 would fix variables 0-99 and 300-399 to their values in the incumbent and solve for the rest, while sub-MIP 2 would fix variables 0-99 and 200-299.

The parameter PartitionPlace controls the use of the heursitic. The parition numbers are specified through the option .partition. The syntax for dot options is explained in the Introduction chapter of the Solver Manual.

Default: 0

partitionplace (integer): Controls when the partition heuristic runs ↵

Setting the Partition attribute on at least one variable in a model enables the partitioning heuristic, which uses large-neighborhood search to try to improve the current incumbent solution.

This parameter determines where that heuristic runs. Options are:

• Before the root relaxation is solved (16)
• At the start of the root cut loop (8)
• At the end of the root cut loop (4)
• At the nodes of the branch-and-cut search (2)
• When the branch-and-cut search terminates (1)

The parameter value is a bit vector, where each bit turns the heuristic on or off at that place. The numerical values next to the options listed above indicate which bit controls the corresponding option. Thus, for example, to enable the heuristic at the beginning and end of the root cut loop (and nowhere else), you would set the 8 bit and the 4 bit to 1, which would correspond to a parameter value of 12.

The default value of 15 indicates that Gurobi enables every option except the first one listed above.

See also Gurobi Documentation.

Default: 15

pdhgabstol (real): PDHG absolute feasibility tolerance ↵

The PDHG algorithm will terminate if both of the following conditions are satisfied:

• The relative difference between the primal and dual objective values is less than pdhgconvtol, and
• The primal and dual solution values meet the specified feasibility tolerance. This is satisfied if either: the absolute residuals of all primal and dual equations are below pdhgabstol; or the relative residuals of all primal and dual equations are below pdhgreltol.
• the absolute residuals of all primal and dual equations are below pdhgabstol; or
• the relative residuals of all primal and dual equations are below pdhgreltol.

You can set PDHGAbsTol to loosen or tighten the second termination criterion. Note though that relative tolerances typically lead to earlier termination than absolute tolerances. If you wish to terminate PDHG based solely on absolute tolerances, you should set pdhgreltol to zero (0).

The first criterion is controlled by pdhgconvtol.

Note: PDHG only

See also Gurobi Documentation.

Default: 1e-06

pdhgconvtol (real): PDHG convergence tolerance ↵

The PDHG algorithm will terminate if both of the following conditions are satisfied:

• The relative difference between the primal and dual objective values is less than pdhgconvtol, and
• The primal and dual solution values meet the specified feasibility tolerance. This is satisfied if either: the absolute residuals of all primal and dual equations are below pdhgabstol; or the relative residuals of all primal and dual equations are below pdhgreltol.
• the absolute residuals of all primal and dual equations are below pdhgabstol; or
• the relative residuals of all primal and dual equations are below pdhgreltol.

You can set PDHGConvTol to loosen or tighten the first termination criterion.

The second criterion is controlled by pdhgabstol and pdhgreltol.

Note: PDHG only

See also Gurobi Documentation.

Default: 1e-06

pdhgiterlimit (real): PDHG iteration limit ↵

Limits the number of PDHG iterations performed.

The PDHG algorithm will terminate if this limit is exceeded. If crossover is enabled, it will start from the final PDHG iterate. If crossover is disabled, optimization will return with an Iteration Interrupt status.

Note: PDHG only

See also Gurobi Documentation.

Default: maxdouble

pdhgreltol (real): PDHG relative feasibility tolerance ↵

The PDHG algorithm will terminate if both of the following conditions are satisfied:

• The relative difference between the primal and dual objective values is less than pdhgconvtol, and
• The primal and dual solution values meet the specified feasibility tolerance. This is satisfied if either: the absolute residuals of all primal and dual equations are below pdhgabstol; or the relative residuals of all primal and dual equations are below pdhgreltol.
• the absolute residuals of all primal and dual equations are below pdhgabstol; or
• the relative residuals of all primal and dual equations are below pdhgreltol.

You can set PDHGRelTol to loosen or tighten the second termination criterion.

If you set PDHGRelTol to the special value zero (0), then only the absolute feasibility tolerances are considered. Specifically, primal and dual solutions are considered feasible only if the residuals of all primal and dual equations are below pdhgabstol.

The first criterion is controlled by pdhgconvtol.

Note: PDHG only

See also Gurobi Documentation.

Default: 1e-06

perturbvalue (real): Simplex perturbation magnitude ↵

Magnitude of the simplex perturbation. Note that perturbation is only applied when progress has stalled, so the parameter will often have no effect.

See also Gurobi Documentation.

Range: [0, ∞]

Default: 0.0002

poolgap (real): Relative gap for solutions in pool ↵

Determines how large a (relative) gap to tolerate in stored solutions. When this parameter is set to a non-default value, solutions whose objective values exceed that of the best known solution by more than the specified (relative) gap are discarded. For example, if the MIP solver has found a solution at objective 100, then a setting of PoolGap=0.2 would discard solutions with objective worse than 120 (assuming a minimization objective).

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

poolgapabs (real): Absolute gap for solutions in pool ↵

Determines how large a (absolute) gap to tolerate in stored solutions. When this parameter is set to a non-default value, solutions whose objective values exceed that of the best known solution by more than the specified (absolute) gap are discarded. For example, if the MIP solver has found a solution at objective 100, then a setting of PoolGapAbs=20 would discard solutions with objective worse than 120 (assuming a minimization objective).

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

poolsearchmode (integer): Choose the approach used to find additional solutions ↵

Selects different modes for exploring the MIP search tree. With the default setting (PoolSearchMode=0), the MIP solver tries to find an optimal solution to the model. It keeps other solutions found along the way, but those are incidental. By setting this parameter to a non-default value, the MIP search will continue after the optimal solution has been found in order to find additional, high-quality solutions. With a non-default value (PoolSearchMode=1 or PoolSearchMode=2), the MIP solver will try to find n solutions, where n is determined by the value of the poolsolutions parameter. With a setting of 1, there are no guarantees about the quality of the extra solutions, while with a setting of 2, the solver will find the n best solutions. The cost of the solve will increase with increasing values of this parameter.

Once optimization is complete, the PoolObjBound attribute can be used to evaluate the quality of the solutions that were found. For example, a value of PoolObjBound=100 indicates that there are no other solutions with objective better 100, and thus that any known solutions with objective better than 100 are better than any as-yet undiscovered solutions.

See Solution Pool for more information about solution pools, including subtleties and limitations.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 0

poolsolutions (integer): Number of solutions to keep in pool ↵

Determines how many MIP solutions are stored. For the default value of poolsearchmode, these are just the solutions that are found along the way in the process of exploring the MIP search tree. For other values of poolsearchmode, this parameter sets a target for how many solutions to find, so larger values will impact performance.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 10

precrush (boolean): Allows presolve to translate constraints on the original model to equivalent constraints on the presolved model ↵

Shuts off a few reductions in order to allow presolve to transform any constraint on the original model into an equivalent constraint on the presolved model. You should consider setting this parameter to 1 if you are using callbacks to add your own cuts. A cut that cannot be applied to the presolved model will be silently ignored. The impact on the size of the presolved problem is usually small.

See also Gurobi Documentation.

Default: 0

predeprow (integer): Presolve dependent row reduction ↵

Controls the presolve dependent row reduction, which eliminates linearly dependent constraints from the constraint matrix. The default setting (-1) applies the reduction to continuous models but not to MIP models. Setting 0 turns the reduction off for all models. Setting 1 turns it on for all models.

See also Gurobi Documentation.

Default: -1

predual (integer): Presolve dualization ↵

Controls whether presolve forms the dual of a continuous model. Depending on the structure of the model, solving the dual can reduce overall solution time. The default setting uses a heuristic to decide. Setting 0 forbids presolve from forming the dual, while setting 1 forces it to take the dual. Setting 2 employs a more expensive heuristic that forms both the presolved primal and dual models (on two threads), and heuristically chooses one of them.

Note: Mainly affects LP, QP, and QCP models, but it is also used for the initial root relaxation of mixed integer programs.

See also Gurobi Documentation.

Default: -1

premiqcpform (integer): Format of presolved MIQCP model ↵

Determines the format of the presolved version of an MIQCP model. Option 0 leaves the model in MIQCP form, so the branch-and-cut algorithm will operate on a model with arbitrary quadratic constraints. Option 1 always transforms the model into MISOCP form; quadratic constraints are transformed into second-order cone constraints. Option 2 always transforms the model into disaggregated MISOCP form; quadratic constraints are transformed into rotated cone constraints, where each rotated cone contains two terms and involves only three variables.

The default setting (-1) choose automatically. The automatic setting works well, but there are cases where forcing a different form can be beneficial.

Note: Only affects MIQCP models

See also Gurobi Documentation.

Default: -1

prepasses (integer): Presolve pass limit ↵

Limits the number of passes performed by presolve. The default setting (-1) chooses the number of passes automatically. You should experiment with this parameter when you find that presolve is consuming a large fraction of total solve time.

See also Gurobi Documentation.

Default: -1

preqlinearize (integer): Presolve Q matrix linearization ↵

Controls presolve Q matrix linearization. Binary variables in quadratic expressions provide some freedom to state the same expression in multiple different ways. Options 1 and 2 of this parameter attempt to linearize quadratic constraints or a quadratic objective, replacing quadratic terms with linear terms, using additional variables and linear constraints. This can potentially transform an MIQP or MIQCP model into an MILP. Option 1 focuses on producing an MILP reformulation with a strong LP relaxation, with a goal of limiting the size of the MIP search tree. Option 2 aims for a compact reformulation, with a goal of reducing the cost of each node. Option 0 attempts to leave Q matrices unmodified; it won't add variables or constraints, but it may still perform adjustments on quadratic objective functions to make them positive semi-definite (PSD). The default setting (-1) chooses automatically.

Note: Only affects MIQP and MIQCP models

See also Gurobi Documentation.

Default: -1

Presolve (integer): Presolve level ↵

Controls the presolve level. A value of -1 corresponds to an automatic setting. Other options are off (0), conservative (1), or aggressive (2). More aggressive application of presolve takes more time, but can sometimes lead to a significantly tighter model.

See also Gurobi Documentation.

Default: -1

presos1bigm (real): Controls largest coefficient in SOS1 reformulation ↵

Controls the automatic reformulation of SOS1 constraints into binary form. SOS1 constraints are often handled more efficiently using a binary representation. The reformulation often requires big-M values to be introduced as coefficients. This parameter specifies the largest big-M that can be introduced by presolve when performing this reformulation. Larger values increase the chances that an SOS1 constraint will be reformulated, but very large values (e.g., 1e8) can lead to numerical issues.

The default value of -1 chooses a threshold automatically. You should set the parameter to 0 to shut off SOS1 reformulation entirely, or a large value to force reformulation.

Please refer to this section for more information on SOS constraints.

See also Gurobi Documentation.

Range: [-1, 1e+10]

Default: -1

presos1encoding (integer): Controls SOS1 reformulation ↵

Controls the automatic reformulation of SOS1 constraints. Such constraints can be handled directly by the MIP branch-and-cut algorithm, but they are often handled more efficiently by reformulating them using binary or integer variables. There are several diffent ways to perform this reformulation; they differ in their size and strength. Smaller reformulations add fewer variables and constraints to the model. Stronger reformulations reduce the number of branch-and-cut nodes required to solve the resulting model.

Options 0 and 1 of this parameter encode an SOS1 constraint using a formulation whose size is linear in the number of SOS members. Option 0 uses a so-called multiple choice model. It usually produces an LP relaxation that is easier to solve. Option 1 uses an incremental model. It often gives a stronger representation, reducing the amount of branching required to solve harder problems.

Options 2 and 3 of this parameter encode the SOS1 using a formulation of logarithmic size. They both only apply when all the variables in the SOS1 are non-negative. Option 3 additionally requires that the sum of the variables in the SOS1 is equal to 1. Logarithmic formulations are often advantageous when the SOS1 constraint has a large number of members. Option 2 focuses on a formulation whose LP relaxation is easier to solve, while option 3 has better branching behavior.

The default value of -1 chooses a reformulation for each SOS1 constraint automatically.

Note that the reformulation of SOS1 constraints is also influenced by the presos1bigm parameter. To shut off the reformulation entirely you should set that parameter to 0.

Please refer to this section for more information on SOS constraints.

See also Gurobi Documentation.

Default: -1

presos2bigm (real): Controls largest coefficient in SOS2 reformulation ↵

Controls the automatic reformulation of SOS2 constraints into binary form. SOS2 constraints are often handled more efficiently using a binary representation. The reformulation often requires big-M values to be introduced as coefficients. This parameter specifies the largest big-M that can be introduced by presolve when performing this reformulation. Larger values increase the chances that an SOS2 constraint will be reformulated, but very large values (e.g., 1e8) can lead to numerical issues.

The default value of -1 chooses a threshold automatically. You should set the parameter to 0 to shut off SOS2 reformulation entirely, or a large value to force reformulation.

Please refer to this section for more information on SOS constraints.

See also Gurobi Documentation.

Range: [-1, 1e+10]

Default: -1

presos2encoding (integer): Controls SOS2 reformulation ↵

Controls the automatic reformulation of SOS2 constraints. Such constraints can be handled directly by the MIP branch-and-cut algorithm, but they are often handled more efficiently by reformulating them using binary or integer variables. There are several diffent ways to perform this reformulation; they differ in their size and strength. Smaller reformulations add fewer variables and constraints to the model. Stronger reformulations reduce the number of branch-and-cut nodes required to solve the resulting model.

Options 0 and 1 of this parameter encode an SOS2 constraint using a formulation whose size is linear in the number of SOS members. Option 0 uses a so-called multiple choice model. It usually produces an LP relaxation that is easier to solve. Option 1 uses an incremental model. It often gives a stronger representation, reducing the amount of branching required to solve harder problems.

Options 2 and 3 of this parameter encode the SOS2 using a formulation of logarithmic size. They both only apply when all the variables in the SOS2 are non-negative. Option 3 additionally requires that the sum of the variables in the SOS2 is equal to 1. Logarithmic formulations are often advantageous when the SOS2 constraint has a large number of members. Option 2 focuses on a formulation whose LP relaxation is easier to solve, while option 3 has better branching behavior.

The default value of -1 chooses a reformulation for each SOS2 constraint automatically.

Note that the reformulation of SOS2 constraints is also influenced by the presos2bigm parameter. To shut off the reformulation entirely you should set that parameter to 0.

Please refer to this section for more information on SOS constraints.

See also Gurobi Documentation.

Default: -1

presparsify (integer): Presolve sparsify reduction ↵

Controls the presolve sparsify reduction. This reduction can sometimes significantly reduce the number of non-zero values in the presolved model. Value 0 shuts off the reduction, while value 1 forces it on for mixed integer programming (MIP) models and value 2 forces it on for all types of models, including linear programming (LP) models, and MIP relaxations. The default value of -1 chooses automatically.

See also Gurobi Documentation.

Default: -1

printoptions (boolean): List values of all options to GAMS listing file ↵

Default: 0

value	meaning
0	Do not list option values to GAMS listing file
1	List option values to GAMS listing file

.prior (real): Branching priorities ↵

GAMS allows to specify priorities for discrete variables only. Gurobi can detect that continuous variables are implied discrete variables and can utilize priorities. Such priorities can be specified through a GAMS/Gurobi solver option file. The syntax for dot options is explained in the Introduction chapter of the Solver Manual. The priorities are only passed on to Gurobi if the model attribute priorOpt is turned on.

Default: 1

projimpliedcuts (integer): Projected implied bound cut generation ↵

Controls projected implied bound cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

psdcuts (integer): PSD cut generation ↵

Controls PSD cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects models with nonconvex quadratic expressions in the objective or constraints

See also Gurobi Documentation.

Default: -1

psdtol (real): Positive semi-definite tolerance ↵

Sets a limit on the amount of diagonal perturbation that the optimizer is allowed to perform on a Q matrix in order to correct minor PSD violations. If a larger perturbation is required, the optimizer will terminate with a Q_NOT_PSD error.

Note: Only affects QP, QCP, MIQP, and MIQCP models

See also Gurobi Documentation.

Range: [0, ∞]

Default: 1e-06

pumppasses (integer): Feasibility pump heuristic control ↵

Number of passes of the feasibility pump heuristic.

This heuristic is quite expensive, and generally produces poor quality solutions. You should generally only use it if other means, including exploration of the tree with default settings, fail to produce a feasible solution.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

qcpdual (boolean): Compute dual variables for QCP models ↵

Determines whether dual variable values are computed for QCP models. Computing them can add significant time to the optimization, so you should only set this parameter to 1 if you need them.

See also Gurobi Documentation.

Default: 0

qextractalg (integer): quadratic extraction algorithm in GAMS interface ↵

Default: 0

value	meaning
0	Automatic
1	ThreePass: Uses a three-pass forward / backward / forward AD technique to compute function / gradient / Hessian values and a hybrid scheme for storage.
2	DoubleForward: Uses forward-mode AD to compute and store function, gradient, and Hessian values at each node or stack level as required. The gradients and Hessians are stored in linked lists.
3	Concurrent: Uses ThreePass and DoubleForward in parallel. As soon as one finishes, the other one stops.

qextractdenseswitchfactor (real): Sparse/dense factor for quadratic extraction algorithm in GAMS interface ↵

Default: 0.008

qextractdenseswitchlog (boolean): Enables additional information about sparse/dense factor choice in quadratic extraction algorithm in GAMS interface ↵

Default: 0

quad (integer): Quad precision computation in simplex ↵

Enables or disables quad precision computation in simplex. The -1 default setting allows the algorithm to decide. Quad precision can sometimes help solve numerically challenging models, but it can also significantly increase runtime. Quad precision is only available on processors that support quadruple precision, e.g., common Intel processors. On other processors, the parameter has no effect.

See also Gurobi Documentation.

Default: -1

readparams (string): Read Gurobi parameter file ↵

relaxliftcuts (integer): Relax-and-lift cut generation ↵

Controls relax-and-lift cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

rerun (integer): Resolve without presolve in case of unbounded or infeasible ↵

In case Gurobi reports Model was proven to be either infeasible or unbounded, this option decides about a resolve without presolve which will determine the exact model status. If the option is set to auto and the model fits into demo limits, the problems is resolved.

Default: -1

value	meaning
-1	No
0	Auto
1	Yes

rins (integer): RINS heuristic ↵

Frequency of the RINS heuristic. Default value (-1) chooses automatically. A value of 0 shuts off RINS. A positive value n applies RINS at every n-th node of the MIP search tree.

Increasing the frequency of the RINS heuristic shifts the focus of the MIP search away from proving optimality, and towards finding good feasible solutions. Gurobi recommends that you try mipfocus, improvestartgap, improvestarttime, improvestartwork, or improvestartnodes before experimenting with this parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

rltcuts (integer): RLT cut generation ↵

Controls Relaxation Linearization Technique (RLT) cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

rngrestart (string): Write GAMS readable ranging information file ↵

If the extension specified is gdx, a GDX file is exported, and a GAMS file otherwise.

scaleflag (integer): Model scaling ↵

Controls model scaling. By default, the rows and columns of the model are scaled in order to improve the numerical properties of the constraint matrix. The scaling is removed before the final solution is returned. Scaling typically reduces solution times, but it may lead to larger constraint violations in the original, unscaled model. Turning off scaling (ScaleFlag=0) can sometimes produce smaller constraint violations. Choosing a different scaling option can sometimes improve performance for particularly numerically difficult models. Using geometric mean scaling (ScaleFlag=2) is especially well suited for models with a wide range of coefficients in the constraint matrix rows or columns. Settings 1 and 3 are not as directly connected to any specific model characteristics, so experimentation with both settings may be needed to assess performance impact.

See also Gurobi Documentation.

Default: -1

seed (integer): Modify the random number seed ↵

Modifies the random number seed. This acts as a small perturbation to the solver, and typically leads to different solution paths.

See also Gurobi Documentation.

Default: 0

sensitivity (boolean): Provide sensitivity information ↵

Default: 0

value	meaning
0	Do not provide sensitivity information
1	Provide sensitivity information

sifting (integer): Sifting within dual simplex ↵

See also Gurobi Documentation.

Default: -1

value	meaning
-1	Automatic
0	Off
1	Moderate
2	Aggressive

siftmethod (integer): LP method used to solve sifting sub-problems ↵

Changing the value of this parameter rarely produces a significant benefit.

See also Gurobi Documentation.

Default: -1

value	meaning
-1	Automatic
0	Primal Simplex
1	Dual Simplex
2	Barrier

simplexpricing (integer): Simplex variable pricing strategy ↵

Changing the value of this parameter rarely produces a significant benefit.

See also Gurobi Documentation.

Default: -1

value	meaning
-1	Automatic
0	Partial Pricing
1	Steepest Edge
2	Devex
3	Quick-Start Steepest Edge

softmemlimit (real): Soft memory limit ↵

Limits the total amount of memory (in GB, i.e., \(10^9\) bytes) available to Gurobi. If more is needed, Gurobi will terminate with a MEM_LIMIT status code.

In contrast to the memlimit parameter, the softmemlimit parameter leads to a graceful exit of the optimization, such that it is possible to retrieve solution information afterwards or (in the case of a MIP solve) resume the optimization.

A disadvantage compared to memlimit is that the softmemlimit is only checked at places where optimization can be terminated gracefully, so memory use may exceed the limit between these checks.

Note that allocated memory is tracked across all models within a Gurobi environment. If you create multiple models in one environment, these additional models will count towards overall memory consumption.

Memory usage is also tracked across all threads. One consequence of this is that termination may be non-deterministic for multi-threaded runs.

See also Gurobi Documentation.

Default: maxdouble

solfiles (string): Location to store intermediate solution files ↵

During the MIP solution process, multiple incumbent solutions are typically found on the path to finding a proven optimal solution. Setting this parameter to a non-empty string causes these solutions to be written to files (in .sol format) as they are found. The MIP solver will append _n.sol to the value of the parameter to form the name of the file that contains solution number \(n\). For example, setting the parameter to value solutions/mymodel will create files mymodel_0.sol, mymodel_1.sol, etc., in directory solutions.

Note that intermediate solutions can be retrieved as they are generated through a callback (by requesting the MIPSOL_SOL in a MIPSOL callback). This parameter makes the process simpler.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

solnpool (string): Controls export of alternate MIP solutions ↵

The GDX file specified by this option will contain a set call index that contains the names of GDX files with the individual solutions. For details see example model dumpsol in the GAMS Test Library. The option PoolSolutions, PoolSearchModel, and PoolGap control the search for alternative solutions. Please also refer to the secion Solution Pool.

solnpoolmerge (string): Controls export of alternate MIP solutions for merged GDX solution file ↵

Similar to SolnPool this option stores multiple alternative solutions to a MIP problem, but in a single GDX file. The GDX file specified by this option will contain all variables with an additional first index (determined through SolnPoolPrefix) as parameters. The option PoolSolutions, PoolSearchModel, and PoolGap control the search for alternative solutions. Please also refer to the secion Solution Pool.

solnpoolnumsym (integer): Maximum number of variable symbols when writing merged GDX solution file ↵

Default: 10

solnpoolprefix (string): First dimension of variables for merged GDX solution file or file name prefix for GDX solution files ↵

Default: soln

solutionlimit (integer): MIP feasible solution limit ↵

Limits the number of feasible MIP solutions found. Optimization returns with a SOLUTION_LIMIT status once the limit has been reached. To find a feasible solution quickly, Gurobi executes additional feasible point heuristics when the solution limit is set to exactly 1.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxint

solutiontarget (integer): Specify the solution target for LP ↵

See also Gurobi Documentation.

Default: -1

value	meaning
-1	Automatic
0	primal dual optimal, basic
1	primal dual optimal

solvefixed (boolean): Indicator for solving the fixed problem for a MIP to get a dual solution ↵

Default: 1

value	meaning
0	Do not solve the fixed problem
1	Solve the fixed problem

startnodelimit (integer): Node limit for MIP start sub-MIP ↵

This parameter limits the number of branch-and-bound nodes explored when completing a partial MIP start. The default value of -1 uses the value of the submipnodes parameter. A value of -2 means to only check full MIP starts for feasibility and to ignore partial MIP starts. A value of -3 shuts off MIP start processing entirely. Non-negative values are node limits.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

starttimelimit (real): Time limit for MIP start sub-MIP (in seconds) ↵

This parameter limits the total time (in seconds) spent on completing a partial MIP start.

Note that this parameter will introduce non-determinism - different runs may take different paths. Use the startworklimit parameter for deterministic results.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

startworklimit (real): Work limit for MIP start sub-MIP (in work units) ↵

This parameter limits the total work (in work units) spent on completing a partial MIP start.

In contrast to the starttimelimit, work limits are deterministic. This means that on the same hardware and with the same parameter and attribute settings, a work limit will stop the optimization of a given model at the exact same point every time. One work unit corresponds very roughly to one second on a single thread, but this greatly depends on the hardware on which Gurobi is running and the model that is being solved.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: maxdouble

strongcgcuts (integer): Strong-CG cut generation ↵

Controls Strong Chvátal-Gomory (Strong-CG) cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

submipcuts (integer): Sub-MIP cut generation ↵

Controls sub-MIP cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

submipnodes (integer): Nodes explored by sub-MIP heuristics ↵

Limits the number of nodes explored by MIP-based heuristics (such as RINS). Exploring more nodes can produce better solutions, but it generally takes longer.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: 500

symmetry (integer): Symmetry detection ↵

Controls symmetry detection. A value of -1 corresponds to an automatic setting. Other options are off (0), conservative (1), or aggressive (2).

Symmetry can impact a number of different parts of the algorithm, including presolve, the MIP tree search, and the LP solution process. Default settings are quite effective, so changing the value of this parameter rarely produces a significant benefit.

See also Gurobi Documentation.

Default: -1

threads (integer): Number of parallel threads to use ↵

Controls the number of threads to apply to parallel algorithms (concurrent LP, parallel barrier, parallel MIP, etc.). The default value of 0 is an automatic setting. It will generally use as many threads as there are virtual processors. The number of virtual processors may exceed the number of cores due to hyperthreading or other similar hardware features.

While you will generally get the best performance by using all available cores in your machine, there are a few exceptions. One is of course when you are sharing a machine with other jobs. In this case, you should select a thread count that doesn't oversubscribe the machine.

Gurobi has also found that certain classes of MIP models benefit from reducing the thread count, often all the way down to one thread. Starting multiple threads introduces contention for machine resources. For classes of models where the first solution found by the MIP solver is almost always optimal, and that solution isn't found at the root, it is often better to allow a single thread to explore the search tree uncontested.

Another situation where reducing the thread count can be helpful is when memory is tight. Each thread can consume a significant amount of memory.

Gurobi has made the pragmatic choice to impose a soft limit of 32 threads for the automatic setting (0), because usually, Gurobi's algorithms do not benefit from higher thread counts. Actually, higher thread counts may even hurt performance, because this will often saturate the memory system. If your machine has more virtual processors, and you find that using more threads increases performance, you should feel free to set the parameter to a larger value. Alternatively, you can use the value -1 to indicate that Gurobi should use all available virtual processors, even if the machine has more than 32.

See also Gurobi Documentation.

Default: GAMS threads

timelimit (real): Time limit ↵

Limits the total time expended (in seconds). Optimization returns with a Resource Interrupt status if the limit is exceeded.

Note that optimization may not stop immediately upon hitting the time limit. It will stop after performing the required additional computations of the attributes associated with the terminated optimization. As a result, the Runtime attribute may be larger than the specified TimeLimit upon completion, and repeating the optimization with a TimeLimit set to the Runtime attribute of the stopped optimization may result in additional computations and a larger attribute value.

See also Gurobi Documentation.

Default: GAMS reslim

.trynonlin (boolean): Try nonlinear function general constraint interface for nonlinear constraint ↵

Default: 1

tunecleanup (real): Enables a tuning cleanup phase ↵

Enables a cleanup phase at the end of tuning. The parameter indicates the percentage of total tuning time to devote to this phase, with a goal of reducing the number of parameter changes required to achieve the best tuning result.

See also Gurobi Documentation.

Default: 0

tunecriterion (integer): Specify tuning criterion ↵

Modifies the tuning criterion for the tuning tool. The primary tuning criterion is always to minimize the runtime required to find a proven optimal solution. However, for MIP models that don't solve to optimality within the specified time limit, a secondary criterion is needed. Set this parameter to 1 to use the optimality gap as the secondary criterion. Choose a value of 2 to use the objective of the best feasible solution found. Choose a value of 3 to use the best objective bound. Choose 0 to ignore the secondary criterion and focus entirely on minimizing the time to find a proven optimal solution. The default value of -1 chooses automatically.

Note that values 1 and 3 are unsupported for multi-objective problems.

See also Gurobi Documentation.

Default: -1

tunedynamicjobs (integer): Enables distributed tuning using a dynamic set of workers ↵

Enables distributed parallel tuning, which can significantly increase the performance of the tuning tool. A value of n causes the tuning tool to use a dynamic set of up to n workers in parallel. These workers are used for a limited amount of time and afterwards potentially released so that they are available for other remote jobs. A value of -1 allows the solver to use an unlimited number of workers. Note that this parameter can be combined with tunejobs to get a static set of workers and a dynamic set of workers for distributed tuning. You can use the WorkerPool parameter to provide a distributed worker cluster.

Note that distributed tuning is most effective when the worker machines have similar performance. Distributed tuning doesn't attempt to normalize performance by server, so it can incorrectly attribute a boost in performance to a parameter change when the associated setting is tried on a worker that is significantly faster than the others.

See also Gurobi Documentation.

Default: 0

tunejobs (integer): Enables distributed tuning using a static set of workers ↵

Enables distributed parallel tuning, which can significantly increase the performance of the tuning tool. A value of n causes the tuning tool to use a static set of up to n workers in parallel. Such workers are kept for the whole tuning run. Note that this parameter can be combined with tunedynamicjobs to get a static set of workers and a dynamic set of workers for distributed tuning. You can use the WorkerPool parameter to provide a distributed worker cluster.

Note that distributed tuning is most effective when the worker machines have similar performance. Distributed tuning doesn't attempt to normalize performance by server, so it can incorrectly attribute a boost in performance to a parameter change when the associated setting is tried on a worker that is significantly faster than the others.

See also Gurobi Documentation.

Default: 0

tunemetric (integer): Metric to aggregate results into a single measure ↵

A single tuning run typically produces multiple timing results for each candidate parameter set, either as a result of performing multiple trials, or tuning multiple models, or both. This parameter controls how these results are aggregated into a single measure. The default setting (-1) chooses the aggregation automatically; setting 0 computes the average of all individual results; setting 1 takes the maximum.

See also Gurobi Documentation.

Default: -1

tuneoutput (integer): Tuning output level ↵

Controls the amount of output produced by the tuning tool. Level 0 produces no output; level 1 produces tuning summary output only when a new best parameter set is found; level 2 produces tuning summary output for each parameter set that is tried; level 3 produces tuning summary output, plus detailed solver output, for each parameter set tried.

See also Gurobi Documentation.

Default: 2

tuneresults (integer): Number of improved parameter sets returned ↵

The tuning tool often finds multiple parameter sets that improve over the baseline settings. This parameter controls how many of these sets should be retained when tuning is complete. A non-negative value indicates how many sets should be retained. The default value (-1) retains the efficient frontier of parameter sets. That is, it retains the best set for one changed parameter, the best for two changed parameters, etc. Sets that aren't on the efficient frontier are discarded. If you interested in all the sets, use value -2 for the parameter.

Note that the first set in the results is always the set of parameters which was used for the first solve, the baseline settings. This set serves as the base for any improvement. So if you are interested in the best tuned set of parameters you need to request at least 2 tune results. The first one (with index 0) will be the baseline setting and the second one (with index 1) will be the best set found during tuning.

See also Gurobi Documentation.

Default: -1

tunetargetmipgap (real): A target gap to be reached ↵

A target gap to be reached. As soon as the tuner has found parameter settings that allow Gurobi to reach the target gap for the given model(s), it stops trying to improve parameter settings further. Instead, the tuner switches into the cleanup phase (see tunecleanup parameter).

This parameter only applies if no other secondary tuning criterion than MIPGap is set, i.e., tunecriterion is at its default value or 1.

See also Gurobi Documentation.

Default: 0

tunetargettime (real): A target runtime in seconds to be reached ↵

A target runtime in seconds to be reached. As soon as the tuner has found parameter settings that allow Gurobi to solve the model(s) within the target runtime, it stops trying to improve parameter settings further. Instead, the tuner switches into the cleanup phase (see tunecleanup parameter).

See also Gurobi Documentation.

Default: 0.005

tunetimelimit (real): Time limit for tuning ↵

Limits total tuning runtime (in seconds). The default value is 86400 seconds, i.e., 24 hours.

See also Gurobi Documentation.

Default: 86400

tunetrials (integer): Perform multiple runs on each parameter set to limit the effect of random noise ↵

Performance on a MIP model can sometimes experience significant variations due to random effects. As a result, the tuning tool may return parameter sets that improve on the baseline only due to randomness. This parameter allows you to perform multiple solves for each parameter set, using different seed values for each, in order to reduce the influence of randomness on the results. The default value of 0 indicates an automatic choice that depends on model characteristics.

See also Gurobi Documentation.

Default: 0

Tuning (string): Parameter Tuning ↵

Invokes the Gurobi parameter tuning tool. The mandatory value following the keyword specifies a GAMS/Gurobi option file. All options found in this option file will be used but not modified during the tuning. A sequence of file names specifying existing problem files may follow the option file name. The files can be in MPS, REW, LP, RLP, and ILP format created by the WriteProb option. Gurobi will tune the parameters either for the problem provided by GAMS (no additional problem files specified) or for the suite of problems listed after the GAMS/Gurobi option file name without considering the problem provided by GAMS. The result of such a run is the updated GAMS/Gurobi option file with a tuned set of parameters. In case the option TuneResults is larger than 1, GAMS/Gurobi will create a sequence of GAMS/Gurobi option files. The solver and model status returned to GAMS will be NORMAL COMPLETION and NO SOLUTION. Tuning is incompatible with advanced features like FeasOpt of GAMS/Gurobi.

usebasis (integer): Use basis from GAMS ↵

If UseBasis is not specified, GAMS (via option BRatio) decides if the starting basis or a primal/dual solution is given to Gurobi. If UseBasis is explicitly set in an option file then the basis or a primal/dual solution is passed to Gurobi independent of the GAMS option BRatio. Please note, if Gurobi uses a starting basis presolve will be skipped.

Default: GAMS bratio

value	meaning
0	No basis
1	Supply basis if basis is full otherwise provide primal dual solution
2	Supply basis iff basis is full
3	Supply primal dual solution

varbranch (integer): Branch variable selection strategy ↵

Controls the branch variable selection strategy. The default -1 setting makes an automatic choice, depending on problem characteristics. Available alternatives are Pseudo Reduced Cost Branching (0), Pseudo Shadow Price Branching (1), Maximum Infeasibility Branching (2), and Strong Branching (3).

Changing the value of this parameter rarely produces a significant benefit.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

varhint (boolean): Guide heuristics and branching through variable hints ↵

If you know that a variable is likely to take a particular value in high quality solutions of a MIP model, you can provide this information as a hint. If VarHint option is active, GAMS/Gurobi will pass variable levels rounded to the nearest integer as hints to Gurobi if their level is within TryInt of an integer. The closer the level is to the rounded integer the higher your level of confidence in this hint. Internally this is recalculated into a Gurobi variable hint priority: \([\frac{1}{\max(10^{-6},|x.l-[x.l]|)}]\)

The Gurobi MIP solver will use these variable hints in a number of different ways. Hints will affect the heuristics that Gurobi uses to find feasible solutions, and the branching decisions that Gurobi makes to explore the MIP search tree. In general, high quality hints should produce high quality MIP solutions faster. In contrast, low quality hints will lead to some wasted effort, but shouldn't lead to dramatic performance degradations.

Variables hints and MIP starts are similar in concept, but they behave in very different ways. If you specify a MIP start, the Gurobi MIP solver will try to build a single feasible solution from the provided set of variable values. If you know a solution, you should use a MIP start to provide it to the solver. In contrast, variable hints provide guidance to the MIP solver that affects the entire solution process. If you have a general sense of the likely values for variables, you should provide them through variable hints.

Default: 0

workerpassword (string): Password for distributed worker cluster ↵

When using a distributed algorithm (distributed MIP, distributed concurrent, or distributed tuning), this parameter allows you to specify the password for the distributed worker cluster provided in the WorkerPool parameter.

See also Gurobi Documentation.

workerpool (string): Distributed worker cluster ↵

When using a distributed algorithm (distributed MIP, distributed concurrent, or distributed tuning), this parameter allows you to specify a Remote Services cluster that will provide distributed workers. You should also specify the access password for that cluster, if there is one, in the WorkerPassword parameter.

You can provide a comma-separated list of machines for added robustness. If the first node in the list is unavailable, the client will attempt to contact the second node, etc.

To give an example, if you have a Remote Services cluster that uses port 61000 on a pair of machines named server1 and server2, you could set WorkerPool to server1:61000 server1:61000,server2:61000.

worklimit (real): Work limit ↵

Limits the total work expended (in work units). Optimization returns with a Terminated by Solver status if the limit is exceeded.

In contrast to the timelimit, work limits are deterministic. This means that on the same hardware and with the same parameter and attribute settings, a work limit will stop the optimization of a given model at the exact same point every time. One work unit corresponds very roughly to one second on a single thread, but this greatly depends on the hardware on which Gurobi is running and the model that is being solved.

Note that optimization may not stop immediately upon hitting the work limit. It will stop when the optimization is next in a deterministic state, and it will then perform the required additional computations of the attributes associated with the terminated optimization. As a result, the Work attribute may be larger than the specified WorkLimit upon completion, and repeating the optimization with a WorkLimit set to the Work attribute of the stopped optimization may result in additional computations and a larger attribute value.

See also Gurobi Documentation.

Default: maxdouble

writeparams (string): Write Gurobi parameter file ↵

writeprob (string): Save the problem instance ↵

zerohalfcuts (integer): Zero-half cut generation ↵

Controls zero-half cut generation. Use 0 to disable these cuts, 1 for moderate cut generation, or 2 for aggressive cut generation. The default -1 value chooses automatically. Overrides the cuts parameter.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

zeroobjnodes (integer): Zero objective heuristic control ↵

Number of nodes to explore in the zero objective heuristic.

This heuristic is quite expensive, and generally produces poor quality solutions. You should generally only use it if other means, including exploration of the tree with default settings, fail to produce a feasible solution.

Note: Only affects mixed integer programming (MIP) models

See also Gurobi Documentation.

Default: -1

Setting up a GAMS/Gurobi-Link license

The GAMS/Gurobi-Link requires two licenses:

• A GAMS license with components GAMS/GUROBI-Link and GAMS/BASE (to generate models beyond the demo limits)
• A Gurobi license which you need to get directly from Gurobi

An attempt to use the GAMS/Gurobi solver with a GAMS/Gurobi-Link license but without a properly set up Gurobi license will result in a licensing error with a message describing the problem. For example, the following message is sent to the log when attempting to solve a model with dimensions beyond the community limits:

    --- Executing GUROBI (Solvelink=2): elapsed 0:00:00.047[LST:85]

    Gurobi           32.2.0 rc62c018 Released Aug 26, 2020 WEI x86 64bit/MS Window

    Gurobi link license.
    *** Cannot initialize Gurobi environment.
    *** Could be a missing or invalid license. (status=10009|10009)

To make the GAMS/Gurobi-Link work you do not need to download or install the Gurobi software but only your Gurobi license. GAMS will use it's own Gurobi DLL/shared library, so the Gurobi license has to be valid for the Gurobi version GAMS uses. You can download your Gurobi license from www.gurobi.com. Log in to your Gurobi account and go to Download & Licenses –> Your Gurobi licenses.

Now click on the license you want to download and click on Get License Details. On the license detail page, copy the grbgetkey command on the bottom.

Paste the grbgetkey command to a command/terminal prompt. Your GAMS system directory contains the grbgetkey program, so to make sure it is found you should open the terminal via GAMS Studio or add your GAMS system directory to the path variable. After running the grbgetkey command, you will be asked where you would like to save your Gurobi license.

$ ./grbgetkey [...]
info  : grbgetkey version 9.0.3, build v9.0.3rc0
info  : Contacting Gurobi key server...
info  : Key for license ID [...] was successfully retrieved
info  : License expires at the end of the day on 2021-08-31
info  : Saving license key...

In which directory would you like to store the Gurobi license key file?
[hit Enter to store it in /opt/gurobi]: /home/nb/gurobilic

info  : License [...] written to file /home/nb/gurobilic/gurobi.lic
info  : You may have saved the license key to a non-default location
info  : You need to set the environment variable GRB_LICENSE_FILE before you can use this license key
info  : GRB_LICENSE_FILE=/home/nb/gurobilic/gurobi.lic

Once you have saved your gurobi.lic file, you need to make GAMS/Gurobi aware of that license via environment variable GRB_LICENSE_FILE. The environmentVariables section in the GAMS configuration file (available as of GAMS version 31.1.0) is a convenient way to set the GRB_LICENSE_FILE environment variable. This can either be done by manually opening and editing the gamsconfig.yaml file which can be found in one of the standard locations or via the corresponding GAMS Configuration Editor in GAMS Studio. As a result, the configuration file should contain an entry for environment variable GRB_LICENSE_FILE that points to the Gurobi license, e.g.

[...]
environmentVariables:
  [...]
  - GRB_LICENSE_FILE:
      value: /home/nb/gurobilic/gurobi.lic
[...]

As an alternative you could also set GRB_LICENSE_FILE via the usual OS-specific ways to set environment variables.

To test whether the license setup has been successful, you can solve a model from the GAMS Model library, e.g. [INDUS89], where you should get the following output.

$ gamslib indus89
Copy ASCII : indus89.gms
$ gams indus89 lp gurobi
--- Job indus89 Start 09/01/20 12:41:41 32.2.0 rc62c018 LEX-LEG x86 64bit/Linux
[...]
Gurobi           32.2.0 rc62c018 Released Aug 26, 2020 LEG x86 64bit/Linux

Gurobi link license.
Gurobi library version 9.0.3
[...]
Iteration    Objective       Primal Inf.    Dual Inf.      Time
       0    7.1618935e+31   2.041808e+32   7.161894e+01      0s
    2990    1.1487366e+05   0.000000e+00   0.000000e+00      0s

Solved in 2990 iterations and 0.32 seconds
Optimal objective  1.148736556e+05

User-callback calls 3040, time in user-callback 0.00 sec
LP status(2): Model was solved to optimality (subject to tolerances).
--- Reading solution for model wsisn
*** Status: Normal completion
--- Job indus89.gms Stop 09/01/20 12:29:49 elapsed 0:00:00.835

Note

To install a Gurobi license key as described above, the grbgetkey program needs to be able to communicate with the Gurobi website. If it fails to work, the grbprobe program which can also be found in your GAMS system directory may be used to retrieve the required hardware information which then needs to be manually submitted to the Gurobi Website (detailed instructions can be found here).