Additions, Changes, and Removals in Gurobi 14.0#

Release Highlights#

  • Gurobi 14.0 provides performance improvements across a variety of model families, including LP, MIP, and MINLP. No parameter settings or application code changes are necessary to benefit from these performance improvements. Detailed results will be posted on our website.

  • The ability of the Gurobi Optimizer to find good solutions early with the MIPFocus=1 parameter has been greatly improved, thanks in particular to the integration of the NoRel heuristic with the tree search. Gurobi 14.0 also includes a new PDHG-based heuristic for MIP models, with optional GPU acceleration.

  • In Gurobi 14.0, you can express nonlinear constraints directly using nonlinear expressions, constraint senses, and right-hand sides. You can also set nonlinear objectives.

New Features#

PDHG-Based Heuristic for MIP Models#

New parameters PDHGMIPHeurSolutions, PDHGMIPHeurTime, and PDHGMIPHeurWork have been added to enable and control a new MIP heuristic that runs a branch-and-bound search in which node relaxations are solved using PDHG instead of the default algorithm. When this heuristic is started, it runs before the regular MIP branch-and-bound search, and the latter starts only when the heuristic ends. Whether or not the heuristic uses the GPU, if there is one, is controlled by the PDHGGPU parameter.

Use PDHGMIPHeurTime and PDHGMIPHeurWork to limit, respectively, the time or work spent in this heuristic, and PDHGMIPHeurSolutions to stop once it has found a specific number of solutions. Note that this heuristic may stop before it reaches the specified limits.

This can be useful for models in which node relaxations are expensive to solve with the default algorithm, but PDHG can process them more quickly, making it easier to find good-quality feasible solutions.

Nonlinear Constraints and Objectives#

Gurobi 14 supports Nonlinear Constraints in a more direct way. Unlike for the existing General Nonlinear constraints (which are deprecated in Gurobi 14), you can set constraint senses and right-hand side values through a set of newly added Nonlinear Constraint Attributes.

The following methods and functions have been added or updated across all APIs to add, query and delete nonlinear constraints:

A new nonlinear constraint object class (GRBNLConstr) has been added to the C++, Java, and .NET APIs. Specific nonlinear attributes can be queried and set on these objects using the standard get/set methods.

Similarly you can now directly specify a nonlinear objective. New methods allow setting, querying, and deleting a nonlinear objective function specified as an expression tree:

For details on the expression tree format, refer to Expression Trees. For details on nonlinear objectives, refer to Nonlinear Objectives.

Expression-based nonlinear modeling in .NET#

When using C# or Visual Basic you can now use expression-based modeling patterns to build nonlinear constraints or objecive functions. For example, if x and y are GRBVar objects, then Sqrt(x), x / y, Log(x) * x, and x * x * x all become GRBNLExpr objects. Operations that have no corresponding C# operator (e.g., Sqrt, Log, Logistic) are provided as static factory methods on this class.

Changes in gurobipy#

Nonlinear API#

gurobipy adopts the new Nonlinear Constraints type in version 14. In particular:

If you are upgrading from a previous version, note that the constraint type returned by Model.addConstr for nonlinear expressions will change as a result. For example, in previous versions the following code:

nlc = model.addConstr(y == nlfunc.sin(x))

created a general nonlinear constraint of the form y = f(X), and returned a GenConstr or MGenConstr object. In version 14 this code creates an equivalent nonlinear constraint of the form f(X) == c, and returns an NLConstr or MNLConstr object. The underlying model is slightly different, and the returned object has a different set of attributes available to query.

We generally recommend using Model.setObjective and Model.addConstr to build nonlinear models. The API will create the appropriate constraint or objective type for the provided expression.

For more fine-grained control over nonlinear constraints, you can use:

For more fine-grained control over the separate quadratic and nonlinear components of the objective function, you can use:

Other Changes#

  • Model.cbUseSolution now returns GRB.UNDEFINED instead of GRB.INFINITY if no improved solution is found or the method has been called from GRB.Callback.MIP or GRB.Callback.MIPSOL. Recall that setting a solution within a GRB.Callback.MIP or GRB.Callback.MIPSOL callback only buffers the solution and processes it later. Therefore, when calling Model.cbUseSolution in these cases, the solution cannot be checked for feasibility, and no objective value can be returned.

  • All methods that take a file path as an argument now also accept a pathlib.Path object (or any os.PathLike type).

  • gurobipy now only installs a signal handler to catch CTRL-C interrupts for optimizations started from the main thread, matching Python’s own behavior. This avoids overriding Python’s signal handler when the optimizer is run on a background thread.

Changes to Other APIs#

  • GRBcbsolution now returns GRB_UNDEFINED instead of GRB_INFINITY if no improved solution is found or the routine has been called from a callback other than GRB_CB_MIPNODE. Recall that setting a solution within a GRB_CB_MIP or GRB_CB_MIPSOL callback only buffers the solution and processes it later. Therefore, the solution cannot be checked for feasibility and no objective value can be returned. Similar adjustments were made for C++, .NET, and Java.

  • Java objects GRBEnv, GRBModel, and GRBBatch now implement the AutoCloseable interface.

Other Notable Changes#

  • A new parameter OACuts was introduced to control generation of outer approximation cuts.

  • An MPS or LP file written by Gurobi now contains a comment “Note: variable lower bounds are 0 unless specified otherwise” in the Bounds section.

  • Two new parameters NLBarInitMu and NLBarStartPush were introduced to control the initial behavior of the NL barrier algorithm.

  • Default value for NLBarIterLimit was increased from 1000 to 10000.

  • When performing another presolve in a MIP solve, Gurobi now also prints the presolved model size after that additional presolve. So, a log could now look as follows with the additional “Presolved:” and “Variable types:” lines at the end:

    Optimize a model with 143787 rows, 12502 columns and 358516 nonzeros (Max)
Model fingerprint: 0xcc9adb3f

Model has 605 linear objective coefficients
Variable types: 0 continuous, 12502 integer (12502 binary)
Coefficient statistics:
  Matrix range     [1e+00, 4e+01]
  Objective range  [1e+00, 4e+01]
  Bounds range     [1e+00, 1e+00]
  RHS range        [1e+00, 5e+03]

Presolve removed 140063 rows and 11165 columns
Presolve time: 0.07s
Presolved: 3724 rows, 1337 columns, 12576 nonzeros
Variable types: 0 continuous, 1337 integer (1337 binary)
Performing another presolve...
Presolve removed 3091 rows and 83 columns
Presolve time: 0.02s
Presolved: 633 rows, 1254 columns, 5009 nonzeros
Variable types: 0 continuous, 1254 integer (1254 binary)

  • Gurobi would now use lbzip2 to compress and uncompress *.bz2 files, if it finds this binary in the PATH. This tool uses parallel threads and is often much faster than bzip2.

  • The special meaning of value 1 for the SolutionLimit parameter has been removed. Previously, value 1 implicitly activated some additional heuristics that are good for finding a first feasible solution. This is now no longer the case. We decided that it is more important that any limit parameter, such as TimeLimit or NodeLimit, can only change the solution path at the moment when the limit is hit. From now on, setting SolutionLimit to 1 will not cause any change to the solution path either. In order to get closer to the behavior of previous Gurobi versions, you can activate these additional heuristics by setting the MIPFocus parameter to 1.

  • A new IsConvex attribute has been added to indicate whether the most recent optimization found the objective and constraints to be convex after presolve.

  • A new IsNLP attribute has been added to indicate whether the model contains any nonlinear constraint or objective.

  • The Gurobi Optimizer’s capacity to detect convexity has been extended to nonlinear models in some cases.

  • The new attributes PreCrossoverStatus, PreCrossoverX, and PreCrossoverPi are the preferred aliases for the deprecated attributes BarStatus, BarX, and BarPi. This name change clarifies that the attributes apply to any pre-crossover algorithm (both barrier and PDHG).

  • The --printquality option of gurobi_cl now prints primal and dual residuals for continuous models in addition to violations.

  • When tuning multi-objective models, you can now use the MIP gap as TuneCriterion. If a multi-objective model cannot be solved to optimality within the specified time limit, the tuner first compares parameter settings based on the number of objective passes that remain unsolved. If multiple settings leave the same number of objective passes unsolved, the tuner uses the MIP gap as a secondary criterion and favors the setting with the smaller gap.

  • Setting ConcurrentMethod to 4 when using the concurrent LP solver now runs PDHG, dual simplex, and primal simplex.

Changes in Parameter Inheritance#

When creating a concurrent environment or a multi-objective environment all parameters are left at their default value, instead of their value being copied from the model environment. In addition, the automatic setting of the InheritParams parameter changed from 0 (don’t inherit) to 1 (do inherit). This change means that it no longer matters whether parameters in the model environment are changed before or after the supporting environment is created, as long as they are changed before the optimization is started. Refer to Inheritance of Parameter Values for more details.

Local optimization applicability#

With the introduction of the new nonlinear constraint API the support for General Nonlinear Constraints in local optimization (see OptimalityTarget parameter) has been removed.

Deprecated functionality#

If you are upgrading from a previous version of Gurobi, we recommend first running your code with Gurobi 13 and warnings enabled to catch deprecations in gurobipy. Fixing these deprecated usages will help to keep compatibility for Gurobi 14 and later versions. Warnings can be enabled by running your code with the -X dev or -W default flags. See the Python Development Mode or warnings package documentation for further details.

In Gurobi 14, the following usage is deprecated and will be removed in a future version:

Removal of deprecated functionality#

Removals from gurobipy#

  • Wildcard matching of file paths in the read and Model.read methods has been removed.