After optimizing a problem with MOSEK it is time to retrieve the results. This post explains the philosophy behind the responses and statuses MOSEK returns.
The first thing to know is if the optimization completed successfully. This is indicated by the response code. Anything other than "OK" indicates an error. Typical error responses are "out of memory", "internal error", "error in input data" and so on. A non-OK response means there are no reliable solutions to look for.
Assuming the optimizer terminated without error, the next thing to ask is "why did it terminate?". The answer is provided by the termination code. "OK" means standard termination, reaching the numerical termination criteria at hand. Other termination codes, however, are not errors. They can indicate such reasons for stopping as "reached a given number of solutions", "reached the time limit", "could not make more progress (stall)", "user interruption from a callback function" and so on. In these cases there is usually a useful solution.
Having checked why the optimizer stopped the next question is "What does it think about my problem?". This is answered by the problem status, which, roughly, indicates if the problem was determined to be feasible or not. Problem status can also be unknown if no conclusion was reached.
Finally we can ask "How do I interpret the solution the optimizer returns?". This is indicated by the solution status. Besides a standard primal-dual feasible solution the solver can for instance return a certificate of primal or dual infeasibility. For integer problems solution status will indicate whether the solution is optimal or just feasible. Again, "unknown" is always a possible answer.
If we are happy with problem and solution status it is now time to fetch the results.
Some users will next want to analyze the solution on their own to check that it is numerically satisfying in that violations and gaps are sufficiently small. The last word on whether the solution is satisfactory always belongs to the user; the answer may be good enough even when the problem status is unknown and/or the termination code indicates "stall".
Finally some users may want to know in greater detail how the optimization process proceeded: data such as time taken by the optimizer, number of iterations, solution quality, etc. which normally appear in the log are available as information items.
This completes the discussion mostly from the perspective of the Optimizer API. In other interfaces implementation details will differ, for instance an exception will be thrown in place of a non-OK response code. Details and an example can be found in the "Accessing a solution" section of your API's tutorial and the corresponding response.* example.
