Developing for Compute Server#

Using Gurobi Compute Server typically requires no changes to your program. This section covers the few exceptions.

Coding for Robustness#

Client-server computing introduces a few robustness situations that you wouldn’t face when all of your computation happens on a single machine. Specifically, by passing data between a client and a server, your program is dependent on both machines being available, and on an uninterrupted network connection between the two systems. The queuing and load balancing capabilities of Gurobi Compute Server can handle the vast majority of issues that may come up, but you can take a few additional steps in your program if you want to achieve the maximum possible robustness.

The one scenario you may need to guard against is the situation where you lose the connection to the server while the portion of your program that builds and solves an optimization model is running. Gurobi Compute Server will automatically route queued jobs to another server, but jobs that are running when the server goes down are interrupted (the client will receive a NETWORK error). If you want your program to be able to survive such failures, you will need to architect it in such a way that it will rebuild and resolve the optimization model in response to a NETWORK error. The exact steps for doing so are application dependent, but they generally involve encapsulating the code between the initial Gurobi environment creation and the last Gurobi call into a function that can be reinvoked in case of an error.

Features Not Supported in Compute Server#

As noted earlier, there are a few Gurobi features that are not supported in Compute Server. We’ve mentioned some of them already, but we’ll give the full list here for completeness. You will need to avoid using these features if you want your application to work in a Compute Server environment.

The unsupported features are:

  • User cuts: The MIPNODE callback isn’t supported, so you won’t have the opportunity to add your own cuts. User cuts aren’t necessary for correctness, but applications that heavily rely on them may experience performance issues.

  • User solutions: Passing a feasible solution to Gurobi via the callback function isn’t supported. This means that the corresponding routines for setting a solution in a callback GRBcbsolution in C, GRBCallback::setSolution in C++, GRBCallback.setSolution in Java, GRBCallback.SetSolution in .NET, and Model.cbSetSolution in Python, are not supported.

  • Multithreading within a single Gurobi environment: This isn’t actually supported in Gurobi programs in general, but the results in a Compute Server environment are sufficiently difficult to track down that we wanted to mention it again here. All models built from an environment share a single connection to the Compute Server. This one connection can’t handle multiple simultaneous messages. If you wish to call Gurobi from multiple threads in the same program, you should make sure that each thread works within its own Gurobi environment.

  • Advanced simplex basis routines: The C routines that work with the simplex basis (GRBFSolve, GRBBSolve, GRBBinvColj, GRBBinvRowi, and GRBgetBasisHead) are not supported.