Try our new documentation site (beta).
Developing for Compute Server
With only a few exceptions, using Gurobi Compute Server requires no changes to your program. This section covers the exceptions. We'll talk about additional features that are only available for compute server programs, program robustness issues that may arise specifically in a compute server environment, and we'll give a full list of the Gurobi features that aren't supported in compute server.
Additional Features in Compute Server
Gurobi Compute Server includes a feature that is not available in
other usage environments. If you set the
NonBlocking parameter to 1, any
subsequent optimize calls (
GRBoptimize in C,
GRBModel::optimize in
C++, GRBModel.optimize in
Java, GRBModel.Optimize
in .NET ) return immediately. Your program can do other things while
the optimization proceeds in the background on the server. To
check on whether the optimization has completed, you can query the
Status attribute for the corresponding
model. A value of IN_PROGRESS indicates that the
optimization has not yet completed.
Note that the set of Gurobi calls that you are allowed to make while
optimization is running in the background is severely limited.
Specifically, you can only perform attribute queries, and only for a
few attributes (listed below). Any other calls on the running model,
or on any other models that were built within the same Gurobi
environment, will fail with error code
OPTIMIZATION_IN_PROGRESS.
Note that there are no such restrictions on models built in other environments. Thus, for example, you could create multiple environments, and then have a single client program launch simultaneous optimization jobs within each environment.
As already noted, you are allowed to query the value of the Status
attribute while a non-blocking optimization is in progress. The other
attributes that can be queried are:
ObjVal,
ObjBound,
IterCount,
NodeCount, and
BarIterCount.
In each case, the returned value reflects progress in the optimization
to that point. Any attempt to query the value of
an attribute not on this list will return an
OPTIMIZATION_IN_PROGRESS error.
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 failover 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 absolute maximum 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.
Unsupported Features 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 you want your application to work in a compute server environment.
The unsupported features are:
- Lazy constraints: While we do provide
MIPSOLcallbacks, we don't allow you to add lazy constraints to cut off the associated MIP solutions. - User cuts: The
MIPNODEcallback 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. - Multi-threading within a single Gurobi environment: All models built from an environment share a single socket connection to the Compute Server. This one socket 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.
