YALMIP is returning that a program is infeasible when it is not

2.1k views Asked by At

I'm having a problem trying to use YALMIP; I suspect I'm doing something silly and I would greatly appreciate if someone pointed out what it is.

I'm trying to solve some SDPs. When I don't define an objective, YALMIP returns a solution (implying that the problem is feasible). However, when I attach an objective to it, YALMIP returns that the problem is infeasible, which has left me a bit perplexed.

Here's the code for the simplest SDP I could cook up in which the above happens. Declaring the variables and setting the constraints is as follows:

y = sdpvar(6,1);
M = sdpvar(3,3);

C = [0,0,0,0,0,0; 0,0,0,0,0,0; -2,0,1.8,0,2,1; 0,0,0,0,0,0; 1,0,-1,0,-1.2,0;
     0,0,0,0,0,0;];

F = [C*y==0, y(6) == 1, M>=0];

F = [F,M(1,1) == y(1), M(2,1) == y(2), M(3,1) == y(3),...
     M(2,2) == y(4), M(3,2) == y(5), M(3,3) == y(6)];

Now if I merely ask YALMIP to find a feasible solution with

solvesdp(F)

it returns

info: 'Successfully solved (LMILAB)'
problem: 0

and some feasible M and y (I've checked that they indeed are). However, if I append the objective "minimise y(3)" (or indeed any linear combination of the entries of y) with

solvesdp(F,y(3))

it returns that the problem is infeasible:

info: 'Infeasible problem (LMILAB)'
problem: 1

and y and M are full of "NaN" tokens.

Many thanks in advance.

1

There are 1 answers

1
Johan Löfberg On BEST ANSWER

LMILAB should not be used together with YALMIP.

http://users.isy.liu.se/johanl/yalmip/pmwiki.php?n=Solvers.LMILAB

The solver in LMILAB has many deficiencies, and one which becomes crucial here is the fact that the solver lacks support for inequalities. To circumvent this, YALMIP adds double-sided inequalities, which completely destroys the numerical procedures of LMILAB.

Install a more general (and modern) solver such as SeDuMi, SDPT3, or Mosek

http://users.isy.liu.se/johanl/yalmip/pmwiki.php?n=Category.SemidefiniteProgrammingSolver

BTW, you are redundantly defining additional variables y. No reason to have them as separate decision variables and then encode how they relate to M. Simply extract them

y = M(find(tril(ones(3))));