9 Technical guidelines

This section contains some more in-depth technical guidelines for Rmosek package, not strictly necessary for basic use of MOSEK.

9.1 Timing

Unless otherwise mentioned all parameters, information items and log output entries in MOSEK which refer to time measurement are expressed in seconds of wall-clock time.

9.2 Multithreading

Parallelization

The interior-point and mixed-integer optimizers in MOSEK are parallelized. By default MOSEK will automatically select the number of threads. However, the maximum number of threads allowed can be changed by setting the parameter MSK_IPAR_NUM_THREADS and related parameters. This should never exceed the number of cores.

The speed-up obtained when using multiple threads is highly problem and hardware dependent. We recommend experimenting with various thread numbers to determine the optimal settings. For small problems using multiple threads may be counter-productive because of the associated overhead. Note also that not all parts of the algorithm can be parallelized, so there are times when CPU utilization is only 1 even if more cores are available.

Determinism

By default the optimizer is run-to-run deterministic, which means that it will return the same answer each time it is run on the same machine with the same input, the same parameter settings (including number of threads) and no time limits.

Setting the number of threads

The number of threads the optimizer uses can be changed with the parameter MSK_IPAR_NUM_THREADS.

9.3 Parallel optimization using the Multicore package

The multicore package works by copying the full memory state of the R session to new processes. While this seems like a large overhead, in practice, the copy is delayed until modification assuring a smooth parallel execution. The downside is that this low-level memory state copy is not safe for all types of resources. As an example, parallel interactions with the GUI or on-screen devices can cause the R session to crash. It is thus recommended only to use the multicore package in console R.

In the Rmosek package a license is an externally acquired resource, and attempts to simply copy the memory state of this resource will provoke a session crash. Thus, licenses should always be released before the time of parallelization.

Always call mosek_clean() before a parallelizing operator. Failure to do so is likely to provoke session crashes.

A consequence of this is that each new process will be using a separate license. That is, your license system should allow as many licenses to be checked out simultaneously, as many parallel optimizations you want to run. Please note that unlimited academic and commercial licenses are available at MOSEK.

9.4 The license system

MOSEK is a commercial product that always needs a valid license to work. MOSEK uses a third party license manager to implement license checking. The number of license tokens provided determines the number of optimizations that can be run simultaneously.

By default a license token remains checked out from the first optimization until the end of the MOSEK session, i.e.

  • a license token is checked out when mosek is called the first time and

  • it is returned when R is terminated, or mosek_clean is called.

Starting the optimization when no license tokens are available will result in an error.

Default behaviour of the license system can be changed in several ways:

  • Setting the parameter MSK_IPAR_CACHE_LICENSE to "MSK_OFF" will force MOSEK to return the license token immediately after the optimization completed.

  • Setting the parameter MSK_IPAR_LICENSE_WAIT will force MOSEK to wait until a license token becomes available instead of returning with an error.

  • The license can be manually released by calling mosek_clean.