 # Can CVX solve SOCP where variables are in the left side?

Hi, guys. I have been working on a second-order convex problem (SOCP) using CVX, which consists of several second-order convex constraints.

Here is my problem. When the variable, for example, w_i, is in the right side, the convex problem can be solved well. For example, when the second-order constraint is like: I_k\geq \sum_{i=1}^K|h_k^Hw_i|^2+\sigma_k^2, the convex problem can be solved. Here, h_k and \sigma_k are given, and I_k is an auxiliary variable.

But when I try to solve another SOCP problem where the second-order constraint is like: e_k\geq \sum_{i=1}^K|\Theta J_kw_i|^2+\sigma_k^2 (Here \Theta is a variable and J_k and w_i are given. e_k is an auxiliary variable.), the status of the problem is still ‘Solved’, however, the second-order constraint itself is not satisfied. When I validate the results of |\Theta J_k|^2, it turns out that some entries of the matrix |\Theta J_kw_i|^2 are negative and some entries are quite large which is incorrect. Because J_k is around 10e-6 and w_i is around 0.01 and also \Theta should satisfy |\Theta|\leq1.

So I was wondering if CVX itself cannot solve the convex problem where the variable is in the right side?

I suggest you start by posting log output.

Here is the post of the output.

## Calling Mosek 9.1.9: 2641 variables, 1171 equality constraints For improved efficiency, Mosek is solving the dual problem.

MOSEK Version 9.1.9 (Build date: 2019-11-21 11:34:40)
Platform: Windows/64-X86

MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (43) of matrix ‘A’.
MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (44) of matrix ‘A’.
MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (45) of matrix ‘A’.
MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (46) of matrix ‘A’.
MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (47) of matrix ‘A’.
MOSEK warning 710: #80 (nearly) zero elements are specified in sparse col ‘’ (48) of matrix ‘A’.
MOSEK warning 710: #2 (nearly) zero elements are specified in sparse col ‘’ (294) of matrix ‘A’.
MOSEK warning 710: #2 (nearly) zero elements are specified in sparse col ‘’ (295) of matrix ‘A’.
MOSEK warning 710: #2 (nearly) zero elements are specified in sparse col ‘’ (298) of matrix ‘A’.
MOSEK warning 710: #2 (nearly) zero elements are specified in sparse col ‘’ (299) of matrix ‘A’.
Warning number 710 is disabled.
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 1171
Cones : 654
Scalar variables : 2641
Matrix variables : 0
Integer variables : 0

Optimizer started.
Presolve started.
Linear dependency checker started.
Linear dependency checker terminated.
Eliminator started.
Freed constraints in eliminator : 0
Eliminator terminated.
Eliminator - tries : 1 time : 0.00
Lin. dep. - tries : 1 time : 0.00
Lin. dep. - number : 0
Presolve terminated. Time: 0.03
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 1171
Cones : 654
Scalar variables : 2641
Matrix variables : 0
Integer variables : 0

Optimizer - solved problem : the primal
Optimizer - Constraints : 637
Optimizer - Cones : 654
Optimizer - Scalar variables : 2364 conic : 2352
Optimizer - Semi-definite variables: 0 scalarized : 0
Factor - setup time : 0.02 dense det. time : 0.00
Factor - ML order time : 0.00 GP order time : 0.00
Factor - nonzeros before factor : 8.66e+04 after factor : 8.85e+04
Factor - dense dim. : 0 flops : 2.48e+07
ITE PFEAS DFEAS GFEAS PRSTATUS POBJ DOBJ MU TIME
0 2.0e+05 1.3e+00 6.6e+02 0.00e+00 6.559261015e+02 -6.969099991e+00 1.0e+00 0.06
1 3.9e+04 2.5e-01 2.9e+02 -1.00e+00 3.358829450e+03 2.700086020e+03 1.9e-01 0.16
2 6.5e+03 4.2e-02 1.2e+02 -1.00e+00 2.010872333e+04 1.947543101e+04 3.3e-02 0.17
3 3.2e+01 2.1e-04 8.4e+00 -1.00e+00 4.132729544e+06 4.138341526e+06 1.6e-04 0.17
4 4.1e+00 2.6e-05 2.9e+00 -9.94e-01 3.090942841e+07 3.095562467e+07 2.0e-05 0.19
5 7.4e-01 4.8e-06 4.8e-01 -5.49e-01 4.012840584e+07 4.016652481e+07 3.7e-06 0.19
6 1.2e-01 7.8e-07 3.5e-02 6.34e-01 4.660195754e+07 4.660948594e+07 6.0e-07 0.19
7 2.2e-02 1.4e-07 2.7e-03 9.62e-01 4.774604992e+07 4.774742904e+07 1.1e-07 0.20
8 5.0e-03 3.2e-08 3.0e-04 9.89e-01 4.794226389e+07 4.794257854e+07 2.5e-08 0.20
9 1.2e-03 7.6e-09 3.3e-05 1.00e+00 4.798715295e+07 4.798722491e+07 5.9e-09 0.22
10 1.7e-04 1.1e-09 1.9e-06 9.96e-01 4.799808430e+07 4.799809514e+07 8.7e-10 0.22
11 2.2e-05 1.4e-10 8.4e-08 9.93e-01 4.799978179e+07 4.799978311e+07 1.1e-10 0.22
12 9.5e-06 1.7e-10 2.5e-08 9.46e-01 4.799990112e+07 4.799990172e+07 4.8e-11 0.23
13 2.8e-06 1.1e-10 3.7e-09 9.53e-01 4.799996944e+07 4.799996960e+07 1.4e-11 0.23
14 1.1e-06 1.4e-10 1.1e-09 8.49e-01 4.799997872e+07 4.799997881e+07 5.7e-12 0.25
15 6.3e-07 2.3e-10 5.2e-10 8.02e-01 4.799997949e+07 4.799997955e+07 3.1e-12 0.25
16 3.5e-07 2.8e-10 2.3e-10 8.72e-01 4.799997997e+07 4.799998001e+07 1.8e-12 0.27
17 2.9e-07 2.3e-10 2.1e-10 2.52e-01 4.799997739e+07 4.799997744e+07 1.4e-12 0.27
18 1.1e-07 7.0e-10 4.1e-11 7.98e-01 4.799997628e+07 4.799997630e+07 5.4e-13 0.27
19 7.4e-08 3.8e-10 2.9e-11 9.25e-02 4.799997063e+07 4.799997065e+07 2.9e-13 0.28
20 2.1e-08 1.8e-09 4.8e-12 7.17e-01 4.799996815e+07 4.799996816e+07 7.9e-14 0.28
21 1.1e-08 9.5e-10 3.2e-12 1.05e-01 4.799996482e+07 4.799996483e+07 4.1e-14 0.30
22 3.7e-09 3.2e-10 9.9e-13 2.81e-01 4.799996144e+07 4.799996145e+07 1.4e-14 0.31
23 9.8e-10 8.5e-11 2.7e-13 8.32e-02 4.799995654e+07 4.799995655e+07 3.7e-15 0.33
Optimizer terminated. Time: 0.36

Interior-point solution summary
Problem status : PRIMAL_AND_DUAL_FEASIBLE
Solution status : OPTIMAL
Primal. obj: 4.7999956541e+07 nrm: 2e+08 Viol. con: 2e-03 var: 0e+00 cones: 0e+00
Dual. obj: 4.7999956553e+07 nrm: 1e+06 Viol. con: 0e+00 var: 4e-09 cones: 2e-16
Optimizer summary
Optimizer - time: 0.36
Interior-point - iterations : 23 time: 0.33
Basis identification - time: 0.00
Primal - iterations : 0 time: 0.00
Dual - iterations : 0 time: 0.00
Clean primal - iterations : 0 time: 0.00
Clean dual - iterations : 0 time: 0.00
Simplex - time: 0.00
Primal simplex - iterations : 0 time: 0.00
Dual simplex - iterations : 0 time: 0.00
Mixed integer - relaxations: 0 time: 0.00

Status: Solved
Optimal value (cvx_optval): -54.334

CVX does not care what side CVX variables or expressions are on, provided they satisfy CVX’s rules.

norm(affine) <= CVX_variable
CVX_variable >= norm(affine)
norm(affine) <= constant
constant >= norm(affine)


are all valid. As well affine can take the place of CVX_variable.

As for your problem, Mosek warned of near-zero input data, which together with the very large optimal objective value (4.8e7 in Mosek), is indicative of bad numerical scaling in your model. Although Mosek claims to have solved the problem, perhaps bad scaling results in your constraints appearing to not be satisfied as closely as you might like. You haven’t even shown us your program, let alone the output which supports your claim of constraints supposedly not being satisfied, so we can’t be very specific in assessing the situation.

I got it. Thank you, Mark. Actually, I have used a scalar variable to validate for a very simple convex problem before, and it works well. So I think it may not be the reason why my program cannot be solved.

I just can’t figure out why the results are so strange. For example, f9 in the following is a CVX expression. I am trying to model it as |\Theta L_kv_i|^2=(\Theta L_kv_i)(\Theta L_kv_i)^H.

    for k=1:K
for kk=1:K
f9(kk,k)=real((theta1*Lk(:,(k-1)*L+1:k*L)*v_i(:,kk))*((theta1*Lk(:,(k-1)*L+1:k*L)*v_i(:,kk)))');
end
end


The output of f9 is as follows.

1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255223678324e-09
1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255228926156e-09
1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255243814869e-09
1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255224688006e-09
1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255225736114e-09
1057310.97435500 1057310.97447271 1057310.97485309 1057310.97380959 1057310.97435787 -3.26255222384500e-09

The entries of the last column of f9 are negative and the rest of f9 are large numbers.

-3.3e-9 is within solver tolerance of being nonnegative, so Mosek considers it to be acceptable to produce such results. if for some reason, you insist on such elements being strictly nonnegative, you will need to incorporate your own buffer into the constraint, such as cvx_variable >= 1e-6.

In any event, the numerical scaling of your problem seems quite bad, and that can cause undesirable things to happen. Try to change the units so that non-zero input data is within a small number of orders of magnitude of one.

Got it. Thank you so much.

I guess I need to change some input values.