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?
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
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.