Documentation


GRBBatch

Gurobi batch object. Batch optimization is a feature available with the Gurobi Cluster Manager. It allows a client program to build an optimization model, submit it to a Compute Server cluster (through a Cluster Manager), and later check on the status of the model and retrieve its solution. For more information, please refer to the Batch Optimization section.

Commonly used methods on the batch object include update (refresh attributes from the Cluster Manager), abort (abort execution of a batch request), retry (retry optimization for an interrupted or failed batch request), discard (remove the batch request and all related information from the Cluster Manager), and getJSONSolution (query solution information for the batch request).

These methods are built on top of calls to the Cluster Manager REST API. They are meant to simplify such calls, but note that you always have the option of calling the REST API directly.

Batch objects have four attributes:

BatchID: Unique ID for the batch request.
BatchStatus: Current optimization status for the batch request. Status values are described in the Batch Status Code section.
BatchErrorCode: Last error code.
BatchErrorMessage: Last error message.
You can access their values by using get. Note that all Batch attributes are locally cached, and are only updated when you create a client-side batch object or when you explicitly update this cache, which can done by calling update.

While the Java garbage collector will eventually collect an unused GRBBatch object, the vast majority of the memory associated with a model is stored outside of the Java heap. As a result, the garbage collector can't see this memory usage, and thus it can't take this quantity into account when deciding whether collection is necessary. We recommend that you call GRBBatch.dispose when you are done with the batch.



Subsections