Problem using 'mosek-geometric' under yalmip

[Mykola Servetnyk]

Hello everyone!

I have both latest versions of Mosek and Yalmip installed on my Matlab2015a. I am trying to solve geometric programming problem that has binary variables. I have specified my options as following

ops2 = sdpsettings('verbose',2,'solver','bnb','bnb.solver','mosek-geometric', 'convertconvexquad',0);

but I get error result 

problem: -3 solver 'mosek-geometric' is not found.

but when I do yalmiptest 

|         MOSEK|            LP/QP|       found|

|         MOSEK|             SOCP|       found|

|         MOSEK|              SDP|       found|

|         MOSEK|        GEOMETRIC|       found|

and before I used Mosek(but not mosek-geometric). The mosek version installed on my PC is standalone version, hence I don't expect any limitations. I use academic-free license.

Hence I have a contradiction: yalmiptest is saying that I have it and problem complains that I don't have it.

Has anyone encountered this kind of issue before? If yes, could you please tell me how to solve it?

Thanks!

[Johan Löfberg]

Works here. Feel very weird, as YALMIP simply checks whether mosekopt is in your path, and there is no difference in yalmiptest vs actually solving a problem using bnb with mosek as lower solver. Reproducible code needed, and/or show us your path, and result from "which mosekopt"

[Johan Löfberg]

code does not run

[Johan Löfberg]

...however, this doesn't look like a geometric program, as you have semidefinite constraints, and logarithmic stuff, so mosek should not be possible to use as lower solver

[Mykola Servetnyk]

However it is possible to run the same thing under cvx... Is there any way to test my 'mosek-geometric'? So that I can make sure that the problem is in my own code.

[Johan Löfberg]

cvx does not do mixed-integer sdp so that statement doesn't make sense. cvx makes a crude approximation of log using socps.

sdp+log can be solved uing scs, so integer+sdp+log can be solved with bnb+scs

this is an example of mixed-integer geometric, solved using mosek as lower solver and your options. solves here

sdpvar t1 t2 t3

obj = (40*t1^-1*t2^-0.5*t3^-1)+(20*t1*t3)+(40*t1*t2*t3);

C = [integer(t1),(1/3)*t1^-2*t2^-2+(4/3)*t2^0.5*t3^-1 <= 1, [t1 t2 t3]>=0];

ops2 = sdpsettings('verbose',2,'solver','bnb','bnb.solver','mosek-geometric', 'convertconvexquad',0);

optimize(C,obj,ops2);

[Mykola Servetnyk]

Thank you! Indeed my mosek-geometric works. So I guess the issue is that yalmip reports 'the solver is not found', but instead it should report 'solver is not applicable' in this case.

[Johan Löfberg]

seems so

[Mykola Servetnyk]

May I also ask, which crude approximation('a crude approximation of log using socps.') you are talking about?, because I want to apply it myself and then still use YALMIP. Many thanks!

[Mark L. Stone]

Johan wrote "cvx does not do mixed-integer sdp".

That depends on what the meaning of "do" is.  Per CVX author Michael Grant, "CVX supports mixed-integer SDPs, but the underlying solvers do not".  So if a solver, for instance, MOSEK, were to produce a version which supports mixed-integer SDPs, then CVX is ready to pass them on to the solver.  See http://ask.cvxr.com/t/mixed-integer-sdps-which-are-not-mixed-integer-socps/477 .

[Johan Löfberg]

Don't, use scs instead (If I remember it correctly, cvx basically uses polynomial approximations iteratively with multiple calls to the solver)

If you want to have a one-shoot approximation,  replace log(x) with t, and log(x) >= t, which is equivalent to x >= exp(t). Now approximate exp(t) as (1+t/n)^n for some n. To implement (1+t/n)^n, use the function cpower

[Mykola Servetnyk]

Thank you very much for your answer!