13. Usage guidelines


The purpose of this chapter is to present some general guidelines to follow when using MOSEK.

13.1. Verifying the results

The main purpose of MOSEK is to solve optimization problems and therefore the most fundamental question to be asked is whether the solution reported by MOSEK is a solution to the desired optimization problem.

There can be several reasons why it might be not case. The most prominent reasons are:

The first step in verifying that MOSEK reports the expected solution is to inspect the solution summary generated by MOSEK; see section 8.7 for details. The solution summary provides information about

By inspecting the solution summary it can be verified that MOSEK produces a feasible solution, and, in the continuous case, the optimality can be checked using the dual solution. Furthermore, the problem itself ca be inspected using the problem analyzer discussed in section 10.1.

If the summary reports conflicting information (e.g. a solution status that does not match the actual solution), or the cause for terminating the solver before a solution was found cannot be traced back to the reasons stated above, it may be caused by a bug in the solver; in this case, please contact MOSEK support.

13.1.1. Verifying primal feasibility

If it has been verified that MOSEK solves the problem correctly but the solution is still not as expected, next step is to verify that the primal solution satisfies all the constraints. Hence, using the original problem it must be determined whether the solution satisfies all the required constraints in the model. For instance assume that the problem has the constraints

\begin{displaymath}\nonumber{}\begin{array}{rcl}\nonumber{}x_{1}+2x_{2}+x_{3} & \leq{} & 1,\\\nonumber{}x_{1},x_{2},x_{3}\geq{}0 &  &\end{array}\end{displaymath}

and MOSEK reports the optimal solution

\begin{displaymath}\nonumber{}x_{1}=x_{2}=x_{3}=1.\end{displaymath}

Then clearly the solution violates the constraints. The most likely explanation is that the model does not match the problem entered into MOSEK, for instance

\begin{displaymath}\nonumber{}x_{1}-2x_{2}+x_{3}\leq{}1\end{displaymath}

may have been inputted instead of

\begin{displaymath}\nonumber{}x_{1}+2x_{2}+x_{3}\leq{}1.\end{displaymath}

A good way to debug such an issue is to dump the problem to OPF file and check whether the violated constraint has been specified correctly.

13.1.2. Verifying optimality

Verifying that a feasible solution is optimal can be harder. However, for continuous problems optimality can verified using a dual solution. Normally, MOSEK will report a dual solution; if that is feasible and has the same objective value as the primal solution, then the primal solution must be optimal.

An alternative method is to find another primal solution that has better objective value than the one reported to MOSEK. If that is possible then either the problem is badly posed or there is bug in MOSEK.

13.2. Turn on logging

While developing a new application it is recommended to turn on logging, so that error and diagnostics messages are displayed.

See example in section 5.2 for instructions on turning log output on. You should also always cache and handle any exceptions thrown by MOSEK.

More log information can be obtained by modifying one or more of the parameters:

By default MOSEK will reduce the amount of log information after the first optimization on a given task. To get full log output on subsequent optimizations set:

mosek.iparam.log_cut_second_opt 0

13.3. Turn on data checking

In the development phase it is useful to use the parameter setting

mosek.iparam.data_check mosek.onoffkey.on

which forces MOSEK to check the input data. For instance, MOSEK looks for NANs in double values and outputs a warning if any are found.

13.4. Debugging an optimization task

If something is wrong with a problem or a solution, one option is to output the problem to an OPF file and inspect it by hand. Use the Task.writedata function to write a task to a file immediately before optimizing, for example as follows:

This will write the problem in task to the file taskdump.opf. Inspecting the text file taskdump.opf may reveal what is wrong in the problem setup.

13.5. Important API limitations

13.5.1. Thread safety

The MOSEK API is thread safe in the sense that any number of threads may use it simultaneously. However, the individual tasks and environments may only be accessed from at most one thread at a time.

13.6. Bug reporting

If you think MOSEK is solving your problem incorrectly, please contact MOSEK support at support@mosek.com providing a detailed description of the problem. MOSEK support may ask for the task file which is produced as follows

task.Task.writedata("taskfile.mbt")
task.Task.optimize()

The task data will then be written to the taskfile.mbt file in binary form which is very useful when reproducing a problem.

Wed Feb 29 16:13:02 2012