7 Overview¶
In this section we present the basic mechanism of the OptServer.
7.1 Synchronous Optimization¶
The easiest way to submit an optimization problem to the OptServer is in synchronous mode, where the caller is blocked while waiting for the optimization:
A submission request is sent over to the OptServer and the problem is transferred.
The submitter is put on hold.
The OptServer runs the optimizer and wait for the results.
When the optimizer terminates the OptServer collects the result and passes over to the client.
The client receives the solution and resumes.
The process can be represented as in Fig. 7.1.
This workflow has the following advantages:
It is effective for problems where the solution is expected reasonably quickly.
The changes to the code compared to a local optimization are almost nonexistent. They boil down to invoking a different method in place of the usual
optimizeor similar.
7.2 Asynchronous Optimization¶
The OptServer accepts jobs also in asynchronous mode, where the client is not blocked while waiting for the result:
A submission request is sent over to the OptServer and the problem is transferred.
The client regains control and continues its own execution flow.
The client can poll the OptServer at any time about the job status and solution availability.
The OptServer runs the optimizer and wait for the results.
When the optimizer terminates the OptServer collects the results, which are available to the client next time it queries.
The process can be represented as in Fig. 7.2.
Asynchronous mode is particularly suitable when
A job is expected to run for long time.
One wants to submit a set of jobs to run in parallel.
The submitter is a short-lived process.
7.3 With or without the MOSEK API¶
Calling OptServer using the MOSEK API
The MOSEK API provides an interface to invoke the OptServer from the client, both in synchronous an asynchronous mode. It is currently available for the Optimizer API (synchronous and asynchronous) and Fusion (synchronous). The API is a set of functions such as optimizermt, asyncoptimize, asyncpoll and similar, which form a replacement for the standard optimize call, while the rest of the MOSEK code (creating task, loading data, retrieving results) remains the same. The details and examples can be found in the manuals for the Optimizer and Fusion APIs. It is possible to retrieve the log via a log handler and to interrupt a solver from a callback handler also during remote optimization. See Sec. 8 (MOSEK API tutorial) for a simple example.
Calling OptServer directly
Alternatively it is possible to call the OptServer through a REST API, submitting an optimization problem in one of formats supported by MOSEK. In this case the caller is responsible for assembling the data, communicating with the solver and interpreting the answer. Details and examples can be found in Sec. 9 (REST API tutorials). Using this approach it is possible to perform optimization from environments that cannot support a MOSEK client, for example from a Web application.
