Cplex&Gurobi can't solve the SOC problem. But Mosek can solve?

[Kris]

Dear Prof:

Hi, I wrote a program, which involved many Soc constraints.

At first, I used Cplex&Gurobi to solve it respectively, both the solver were failed.

Then, I tried Mosek, this solver gave me a good ans. The cost is about 3.66e+05.

The situation makes me confused. 

I'd appreciated it if you can give me some help.

Best wished

Kris

[Johan Löfberg]

So the conclusion is simply that Mosek is better than both Gurobi and CPlex on this instance.

Perhaps you should co-operate with Lily in the other thread. You appear to solve the same problem (taking same class perhaps...)

[Kris]

So, Prof, you can get same ans like mind?

[Johan Löfberg]

no as your code is not reproducible

Error using xlsread (line 139)

XLSREAD unable to open file 'D_Eight.xlsx'.

[Kris]

This problem have confused me for several months. Because both Cplex&Gurobi(They are classical solvers.) can't solve it, therefore, I pretty sure my code is wrong.

Until you told Lily Mosek can solve a Soc problem while Cplex&Gurobi performed badly, I tried Mosek.

Above all, in terms of a problem with many Soc constraints, I should try several solvers to make sure the ans? 

[Kris]

Sorry, I forgot to comment the Line 139, this code can run now.

[Johan Löfberg]

If I find a solver is struggling with a model, I always check with another solver (and simplify the model etc to see what is causing the problem). No solver is perfect.

[Johan Löfberg]

and note that the model the solver gets it not necessarily the model you see

In terms of SOCP models, mosek has a better format when working with yalmip. For a vector c + Ay being constrained to be in the intersection of SOCP cones, mosek can take c and A directly and solve. Gurobi and cplex on the other hand uses a format which is centered on the quadratic versions, i.e in the example of a single socp cone, you effectively send A'*A, c'*c and c'*A in some form to the solvers. This can destroy sparsity, can be be expensive to compute, and can destroy numerical properties as you square things. An alternative is to introduce a new variable z and add the equality z == c+A'y, and then derive the quadratic for z'*z instead, which is sparse (identity) and very simple. The drawback is the additional variables and equalities. For your model, this model is not good as it is huge. In fact, on my machine I cannot even solve your problems using gurobi and cplex, they crash due to memory issues

[Johan Löfberg]

Note that your code runs very slowly due to poor vectorization.

E.g, around 30 seconds is spent on constraint08 = constraint08 + [y0(i,1) + h_00'*s_00(:,i) + h_01'*s_01(:,i) + h_02'*s_02(:,i) + h_03'*s_03(:,i) + h_04'*s_04(:,i) + h_05'*s_05(:,i) + h_06'*s_06(:,i) + h_07'*s_07(:,i) + h_08'*s_08(:,i) + h_09'*s_09(:,i) + h_10'*s_10(:,i) + h_11'*s_11(:,i) + h_12'*s_12(:,i) + h_13'*s_13(:,i) + h_14'*s_14(:,i) + h_15'*s_15(:,i) + h_16'*s_16(:,i) >= 0];

That loop can be removed and all those constraints are simply

constraint08 = constraint08 + [y0 + (h_00'*s_00 + h_01'*s_01 + h_02'*s_02 + h_03'*s_03 + h_04'*s_04 + h_05'*s_05 + h_06'*s_06 + h_07'*s_07 + h_08'*s_08 + h_09'*s_09 + h_10'*s_10 + h_11'*s_11 + h_12'*s_12 + h_13'*s_13 + h_14'*s_14 + h_15'*s_15 + h_16'*s_16)' >= 0];

All those constraints are now defined in fractions of a second. Same thing with the other constraints you have in that loop

Those low-level cones can be improved further also. First note that

[cone(s_01(1:2,i),s_01(3,i))]

is simply

[cone(s_01(:,i))]

and since cone applied to a matrix means cone on every column, all your cones can be done without any for-loop as

cone(s_01)

[Kris]

Dear Prof, thanks for your kindness, your advice improve my code indeed. I will check my code again.

Considering what you told me, I will try off-the-shelf solvers if my ans is bad. (i.e mosek, cplex, gurobi)

Besides, I have another question: 

Convex optimization already have wide range of applications in power system, when we try to figure out a two-stage optimization problem, reformulating it into a single stage second order cone problem is quite a common idea. (i.e My code have transformed a two-stage linear problem into a single stage conic problem)

However, after this practice, I think that it's much better to solve a linear problem than a conic problem, in terms of computational burden. 

Why people always transform one problem into a conic problem? Can you explain me some mathematical advantage of the "Convex idea" ?

[Johan Löfberg]

Your question is coming from a weird premise.

No one uses SOCP programming unless it is necessary due to the problem being solved. If the problem can be modelled using LP, you of course solve it as an LP. And a linear problem is also conic (the non-negative orthant cone)

"Convex idea"? LP and SOCP are both convex. Non-convex is typically much harder to solve (with optimality guarantees)

[Kris]

I see, when we face a quadratic constraints, (i.e power flow constraints in power system), making a soc relaxation is the ideal to solve it?

[Johan Löfberg]

you mean a quadratic equality?. yes an socp relaxation is stronger than an lp approxomation/relaxation