You can use grbcluster to create a batch (i.e., a non-interactive job):
> grbcluster batch solve ResultFile=solution.sol misc07.mps --download info : Batch 5d0ea600-5068-4a0b-bee0-efa26c18f35b created info : Uploading misc07.mps... info : Batch 5d0ea600-5068-4a0b-bee0-efa26c18f35b submitted with job a9700b72... info : Batch 5d0ea600-5068-4a0b-bee0-efa26c18f35b status is COMPLETED info : Results will be stored in directory 5d0ea600-5068-4a0b-bee0-efa26c18f35b info : Downloading solution.sol... info : Downloading gurobi.log... info : Discarding batch data
This command performs a number of steps. First, a batch specification is created and the batch ID is displayed. Then, the model file is uploaded and a batch job is submitted. Once the job reaches the front of the Compute Server queue, it is processed. At that point, the batch is marked as completed and the result file with the log file is automatically downloaded to the client. By default, the directory name where the result file is stored is the batch ID. Finally, the batch data is discarded, which allows the Cluster Manager to delete the associated data from its database.
This is a non-interactive optimization task because it happens in two distinct phases. The first phase uploads the model to the server and creates a batch. The second waits for the batch to complete and retrieves the result. In general, stopping the client has no effect on a batch once it has been submitted to the Cluster Manager. Our example waits for the completion of the batch, but that's only because we used the —download flag. You could check on the status of the batch and download the results whenever (and wherever) they are needed, since they are stored in the Cluster Manager until they are discarded.