14. Usage guidelines


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

14.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.

14.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.

14.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.

14.2. Turn on logging

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

Using the MSK_linkfiletotaskstream function a file can be linked to a task stream. This means that all messages sent to a task stream are also written to a file. As an example consider the code fragment

MSK_linkfiletotaskstream(task,MSK_STREAM_LOG ,"moseklog.txt");

which shows how to link the file moseklog.txt to the log stream.

It is also possible to link a custom function to a stream using the MSK_linkfunctotaskstream function.

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:

MSK_IPAR_LOG_CUT_SECOND_OPT 0

14.3. Turn on data checking

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

MSK_IPAR_DATA_CHECK MSK_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.

14.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 MSK_writedata function to write a task to a file immediately before optimizing, for example as follows:

MSK_writedata(task,"taskdump.opf");
MSK_optimize(task);

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.

14.5. Error handling

Most functions in the C API return a response code which indicates whether an error occurred. It is recommended to check to the response code and in case it is indicating an error then an appropriate action should be taken.

14.6. Fatal error handling

If MOSEK encounter a fatal error caused by either an internal bug or a user error, an exit function is called. It is possible to tell MOSEK to use a custom exit function using the MSK_putexitfunc function. The user-defined exit function will then be called if a fatal error is detected.

The purpose of an exit function is to print out a suitable message that can help diagnose the cause of the error.

14.7. Checking for memory leaks and overwrites

If you suspect that MOSEK or your own application incorrectly overwrites memory or leaks memory, we suggest you use external tools such as Purify or valgrind to pinpoint the cause of the problem.

Alternatively, MOSEK has a memory check feature which can be enabled by letting the argument dbugfile be the name of a writable file when calling MSK_makeenv. If dgbfile is valid file name, then MOSEK will write memory debug information to this file. Assuming memory debugging is turned on, MOSEK will warn about MOSEK specific memory leaks when a MOSEK environment or task is deleted.

Moreover, the functions MSK_checkmemenv and MSK_checkmemtask can be used to check the memory allocated by a MOSEK environment or task at any time. If one these functions finds that the memory has been corrupted a fatal error is generated.

14.8. Important API limitations

14.8.1. Thread safety

The MOSEK API is thread-safe provided that a task is accessed from one thread only at any time.

14.8.2. Unicoded strings

The C API supports the usage of unicoded strings. Indeed all (char *) arguments are allowed to be UTF8 encoded strings.

14.8.2.1. Limitations

Please note that the MPS and LP file formats are ASCII formats. Therefore, it might be advantageous to limit all names of constraints, variables etc. to ASCII strings.

14.9. 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

MSK_writedata(task,"taskfile.mbt");
MSK_optimize(task);

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:08:51 2012