create an interface to Mosek optimisation software

[dimpase]

Mosek makes fast (MI)LP, quadratic and semidefinite programming (SDP) solvers; they come with a free academic license.

A Python interface is provided.

CC: @nathanncohen @mkoeppe @mforets

Component: interfaces: optional

Author: Marcelo Forets

Branch/Commit: u/mforets/18847 @ 350045d

Issue created by migration from https://trac.sagemath.org/ticket/18847

[mforets]

comment:1

hello,

i'm interested in contributing to the MOSEK SDP backend for Sage, but i have no experience in writing Cython library code. Given that there is a project Mosek.pip, i was just wondering if that facilitates in one way or another this task. at the same time one would like that the whole thing works as efficiently as possible.. any feedback is welcome, thanks.

[mkoeppe]

comment:2

This project just seems to provide an installer for Mosek. (This could also be useful for Sage, of course.)
Is there a Python interface available too somewhere? Then we should use that interface rather than writing our own.

[mforets]

comment:3

yes, there is an official Python API.

they claim that "The overhead introduced by this mapping (interface to the native C optimizer) is minimal."

[mkoeppe]

comment:4

Sounds like no Cython programming is necessary then.

[dimpase]

comment:5

if you want to use the unified SemidefiniteProgram() interface in Sage you will need to write a backend; currently the only non-dummy SDP backend in Sage is cvxopt_sdp_backend.pyx
(which is not really Cython, it's just wrapping cvxopt's Python interface)

So a similar job can be done with Mosek's Python SDP interface
(which can as well be used directly, although it is not pretty...)

[mforets]

comment:6

So a similar job can be done with Mosek's Python SDP interface

got it, let me have a look and write back later!

(which can as well be used directly, although it is not pretty...)

.. i want to believe that there's more payoff on these efforts than just aesthetics. python-based modeling interfaces to optimization solvers do exist, such as pyopt, picos or pyomo. if Sage provides extra convenience and functionality for users at different levels then i think that's a sound motivation.

[mforets]

comment:7

i've started by reading Sage's SDP interface. in #23389 and #23390 i've uploaded 2 branches with some typo fixes etc for the html doc.

[dimpase]

comment:8

Replying to @mforets:

So a similar job can be done with Mosek's Python SDP interface

got it, let me have a look and write back later!

(which can as well be used directly, although it is not pretty...)

.. i want to believe that there's more payoff on these efforts than just aesthetics. python-based modeling interfaces to optimization solvers do exist, such as pyopt, picos or pyomo. if Sage provides extra convenience and functionality for users at different levels then i think that's a sound motivation.

One certainly does not want to write different code for a different solver.

My motivation for pushing for a uniform SDP interface in Sage is the problems of polynomial optimisation which are being solved via the moment method.
(I have some particular case of this implemented in Sage, the global optimisation, in need of a cleanup etc...)

[mforets]

comment:9

then we should follow-up on that later: i was planning to port some functionality from YALMIP tool (Matlab).

(aside comments: my experience with yalmip is that when you increase the relaxation order, setting up the problem/symbolics may cost more in cpu / memory than the optimization itself.. AFAIK, for Python there is 1 related project: ncpol2sdpa. that project is great, but i wonder if one can also exploit Sage's fast polynomial libraries, or other compiled code.)

[mforets]

Commit: 350045d

[mforets]

Branch: u/mforets/18847

[mforets]

Author: Marcelo Forets

[mforets]

comment:10

initial commit added, an adaptation of CVXOPT SDP backend.

as it stands, the continuation would be to load Mosek's task with the problem data inside the cpdef int solve function, using some of task.pucj, task.putvarbound, task.appendsparsesymmat, and so on.

but i was thinking if it would be desirable (speed? memory?) to initialize the optimization task at the instantiation of the MOSEKSDPBackend class, and update it when the methods are being called, instead of interacting with Mosek only at its solve method.

---

New commits:

350045d

initial template