Documentation

Next: C API Overview Up: Gurobi Optimizer Reference Manual Previous: Gurobi Optimizer Reference Manual

Detailed Release Notes for Gurobi 11.0.3

Supported Platforms

Gurobi 11.0.3 supports the following language/platform versions:

Bug Fixes

All bug fixes listed by version can be found on our website.

Additional Release Notes for 11.0.3

None

Additional Release Notes for 11.0.2

• The interactive shell (gurobi.sh and gurobi.bat) is deprecated and will be removed in a future release.

Additional Release Notes for 11.0.1

None

Changed in Gurobi 11.0

Linux GNU C library (glibc) dependency

• Linux x86_64: The Gurobi Optimizer now requires a minimum glibc version of 2.17. For version 10.0, the minimum required glibc version was 2.3.4.

  The list of supported platforms above takes these changes into account.

New features affecting all APIs

Mixed-Integer Non-Linear Programming (MINLP) Problems

The Gurobi Optimizer can now use spatial branching and outer approximation to solve models with non-linear functions, instead of using static piecewise-linear approximations. See the discussion of function constraints with dynamic piecewise-linear approximation for more information.

Default behavior of NonConvex parameter

The default behavior of the NonConvex parameter has changed. Previously, you had to explicitly set this parameter to value 2 if you wanted to solve a model with a non-convex quadratic objective or constraint. Now it will solve such models by default. To revert to the previous behavior, set the parameter to 1.

Copying models between environments

It is now possible to copy a model from one environment to another, using the following new routines or signatures:

• C: GRBcopymodeltoenv
• C++: GRBModel(const GRBModel& model, const GRBenv& targetenv)
• Java: GRBModel(GRBModel model, GRBenv targetenv)
• .NET: GRBModel(GRBModel model, GRBenv targetenv)
• Python: model.copy(env)

The primary use case for copying models is when performing optimization on multiple, related versions of the same problem on multiple threads. Multi-threading within an environment is not supported.

For Compute Server users, note that you can copy a model from a client to a Compute Server environment, but it is not possible to copy models between two Compute Server environments.

Better control over the concurrent LP optimizer Option 5 of the Method parameter has been deprecated in favor of the new ConcurrentMethod parameter. The latter allows you to control which methods are run concurrently with the deterministic (Method=4) or non-deterministic (Method=3) concurrent optimizer. The deprecated setting Method=5 can now be replicated by choosing Method=4 along with ConcurrentMethod=3. To give another example, non-deterministic concurrent execution of the primal and dual simplex algorithms can be selected using Method=3 along with ConcurrentMethod=3.

Change the Threads parameter when resuming optimization If an optimization is interrupted (e.g., due to a time limit), the user can now modify the Threads parameter in order to change the number of threads to be used when the solving process is resumed with another call to optimize.

Tuning

The distributed tuning can use remote workers in a dynamic way. With the parameter TuneDynamicJobs you can control the size of a dynamic set of remote workers that are used in parallel. These workers are used for a limited amount of time and afterwards potentially returned so that they are available for other remote jobs.

Starting from Gurobi 11, we include in the results the first set of parameters used to solve the model (base settings). This result is stored as first setting in the tune results. Hence, to get the best tuned set of parameters, you need to request at least 2 sets (using TuneResults) and retrieve the set with index 1.

The tuner now supports the log callback. You can add a log callback to the environment and retrieve all the log messages coming from the tuner.

Piecewise-linear approximation The default behavior of parameter FuncPieces, the main parameter for piecewise-linear approximation of function constraints, is changed. The new default for version 11.0 uses the relative error approach for the approximation, while for version 10.0 or earlier it mainly used the number of function constraints to set the total number of pieces.

New parameters The following parameters are new in Gurobi 11.0:

• SolutionTarget to specify the solution target for LP.
• FuncNonlinear to control whether general function constraints shall be treated as nonlinear functions or via piecewise-linear approximation.
• MixingCut to control the generation of Mixing Cuts.
• TuneDynamicJobs to enable distributed tuning using a dynamic set of workers.
• TuneUseFilename to use the model file names as model names during tuning (Command-line only).

Changes to gurobipy

Installation and packaging changes

• gurobipy and its setup.py file are no longer distributed with the Gurobi installers. gurobipy must now be installed into Python environments using pip or conda.

• The gurobi conda packages have been updated so that pip can now recognize when gurobipy has already been installed into an environment by conda. As a result, using pip in a conda environment to install a package that depends on gurobipy (such as gurobi-machinelearning or gurobipy-pandas) no longer leads to a duplicate installation of gurobipy.

• Type hints for gurobipy are now included in both the pip wheels and conda packages. For Gurobi version 11, users should not install the gurobipy-stubs package as it will override the type annotations packaged with gurobipy. The gurobipy-stubs package will not be maintained for future versions of gurobipy.

New classes, methods, and properties

• SOS objects have a new index property returning the index of the SOS constraint in the model.

• MConstr and MQConstr objects now implement the class method fromlist which has the same behavior as the corresponding method on the MVar class.

• New methods hstack, vstack, and concatenate allow matrix-friendly objects to be joined together in the same way as the corresponding numpy functions.

• A new MGenConstr class has been added for holding an array of general constraints. For version 11, only the addGenConstrIndicator method is able to return objects of this type.

• Env objects now have an additional method getParam which returns the current value of the given parameter in the environment.

Enhancements to existing methods

• The Model.optimize and Model.computeIIS methods now accept any Python callable as a callback function. The TSP example code has been updated to demonstrate the use of a callable class.

• The matrix-friendly API is now fully integrated with callback methods: Model.cbLazy, Model.cbCut, and Model.cbSetSolution now accept matrix-friendly API objects.

• When constructing a set of linear constraints using Model.addMConstr or Model.addConstr with the matrix-friendly API, user-defined constraint names can be passed as a list or ndarray.

• Model.addGenConstrIndicator and the overloaded » syntax for indicator constraints now handle matrix-friendly linear expression objects. This allows indicator constraints to be built in a vectorized manner (including broadcasting behavior).

• Users can now explicitly disable the default environment by setting the environment variable GUROBIPY_ALLOW_DEFAULTENV to 0 before starting a Python program. With this setting, environments must be managed explicitly using Env objects in user code. Calls to Model() without an Env object and global function calls such as setParam will raise a GurobiError if this setting is used.

Changes that may require updating your code

• Model.getAttr and Model.setAttr now raise an exception if the modeling objects passed to them do not belong to the model. Previously, the attribute values would be returned or set for a variable on the model with the same index as the modeling object which is typically not the desired behavior.

• A call to Model.addGenConstrIndicator using size-1 matrix-friendly modeling objects, which previously returned a GenConstr object, will now return a size-1 MGenConstr. The constraint name may also change depending on the shape of the result. To revert to the previous behaviour, call .item() on matrix-friendly modeling objects passed to this function.

• The tupledict now follows Python 3 dictionary semantics: its keys, values, and items methods now return iterable views instead of lists. Importantly, keys no longer returns a tuplelist. If you need this behavior, you can instead call gp.tuplelist(td.keys()).

• Env.setParam now raises a GurobiError if the user specifies a parameter which does not exist. In previous versions, such calls would print a message but would fail without an exception.

• Gurobi log messages now go to the `gurobipy' logger instead of `gurobipy.gurobipy'. If you use Python's logging library to collect Gurobi log messages, handlers should be attached either to the root logger or to logging.getLogger("gurobipy").

• Calling the sum() method of an MVar, MLinExpr, or MQuadExpr which contains no elements (i.e. has at least one zero-length dimension) now returns an array of zeros of the appropriate shape instead of raising an exception. This matches the behavior of numpy arrays.

• Passing too many keys (more than the length of the contained tuples) to any of the pattern matching methods (tuplelist.select, tupledict.select, tupledict.sum, and tupledict.prod) now raises an IndexError. This change almost exclusively affects cases which returned an empty set in previous versions. The exception is where the additional indices are wildcards. i.e. for a tuplelist containing 2-tuples: tl.select("*", 2, "*") now raises an exception, while in previous versions it gives the same (non-empty) result as tl.select("*", 2).

• The gurobi Python package alias has been removed from the conda packages on all platforms. Any usage of import gurobi must be replaced with import gurobipy.

Deprecated functionality

If you are upgrading from a previous version of Gurobi, we recommend first running your code with Gurobi 10 and warnings enabled to catch deprecations in gurobipy. Fixing these deprecated usages will help to keep compatibility for Gurobi 11 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 11, the following usage is deprecated and will be removed in a future version:

• Passing a tupledict to the quicksum function is deprecated as the result is inconsistent with passing a native Python dictionary to quicksum. The sum method of the tupledict should be used instead to compute the sum over the values of the tupledict.

• The iterkeys(), itervalues(), and iteritems() methods for tupledicts are deprecated. These methods are legacy syntax from Python 2. The corresponding Python 3 methods keys(), values(), and items() now return iterable views and are therefore preferred.

• The gurobipy.system() function is deprecated. os.system() from the Python standard library should be used instead.

• The gurobipy.models() function is deprecated and should no longer be used.

Changes to the Java package

Updates

We've made essential changes in the package structure to allow publishing to Maven Central. Please take note of the following updates:

• Package Name Change: The Java package name has been updated from gurobi to com.gurobi.gurobi. If you are integrating our Java package, ensure to update your import statements accordingly.

Changes to the MATLAB interface

On the macOS platform, the Gurobi mex interface is now also available for native Apple silicon MATLAB (mexmaca64).

Compute Server, Cluster Manager, and Instant Cloud

Detailed release notes for Compute Server, Cluster Manager, and Instant Cloud can be found here

Other changes

The interactive shell (gurobi.sh and gurobi.bat) is deprecated and will be removed in a future release.

---

Next: C API Overview Up: Gurobi Optimizer Reference Manual Previous: Gurobi Optimizer Reference Manual