SDP in CVX 3.0 fails due to Subscript indices must either be real positive integers or logicals

Hi,

I am solving an SDP problem in MATLAB.
When I use CVX 3.0, there is an error launched
"Subscript indices must either be real positive integers or logicals."
However, this error doesn’t occur when I use CVX 2.0 version or the same problem with different input data.

For a test of CVX 3.0, I attached my code

clear all; clc;

n = 2; m = 5; s = 5;
alpha = 1e-2;
R = [1 alpha alpha alpha alpha; …
alpha 1 alpha alpha alpha; …
alpha alpha 1 alpha alpha; …
alpha alpha alpha 1 alpha; …
alpha alpha alpha alpha 1];
w0 = zeros(m,1); w0( randi(m,1,s) ) = 1;
X0 = w0w0’;
Z0 = inv( ( 2 * X0 - ones(m,1) * w0’ - w0 * ones(1,m) + ones(m,1) * ones(1,m) ).
R );
H = ones(m,n);

cvx_begin sdp
variable w(m);
variable X(m,m) symmetric;
variable Z(m,m) symmetric;
variable V(m,m) symmetric;
variable T(n,n) symmetric;
expression L1(m,m);
C = Z0; C0 = (2 * X0 - ones(m,1) * w0’ - w0 * ones(1,m));
L1 = C - C * ( ( 2 * X - ones(m,1) * w’ - w * ones(1,m) - C0 ).* R )* C;
expression L2(m,m);
L2 = X.* Z0 + X0.* Z - X0.* Z0;
minimize ( trace(T) + trace(V) );
subject to
trace(X) == s; %%% Linear
diag(X) - w == zeros(m,1); %% linear
[X, w; w.’, 1] >= 0; %%% Linear matrix ineq
[Z, eye(m); eye(m), (2X - ones(m,1) * w’ - w * ones(1,m) + ones(m,1) * ones(1,m)). R] >= 0; %%% LMI
Z - L1 <= V; %% LMI
V >= 0; %% LMI
L2 >= 0; %% LMI
[ (eye(n) + H’ * L2 * H), eye(n); …
eye(n), T] >= 0; %%% LMI
cvx_end

The CVX message is
"
Subscript indices must either be real positive integers or logicals.

Error in cvx_sdpt3>solve (line 211)
Avec{end}{end+1} = reshape( ( str_3 * str_2 ) * reshape( At(ti,:), nt, nv * m ), nt2 * nv, m );

Error in cvx_solve (line 399)
[ x, status, tprec, iters, y ] = shim.solve( At, b, c, cones, params );

Error in cvx_finish (line 57)
[ status, result, bound, iters, tol ] = cvx_solve;

Error in cvx_end (line 11)
evalin( ‘caller’, ‘cvx_finish’ );

Error in Test_CVX (line 39)
cvx_end
"

If we set alpha = 0, then the aforementioned code works for SDP and have the valid output.
"------------------------------------------------------------
Status: Solved
Optimal value (cvx_optval): +3.32964e-10
"

I am wondering the reason for this error. Can you fix it?

Thank you very much,

If it works in CVX 2 and not in CVX 3, then it looks like a bug. Thanks for reporting it!

If I keep using CVX 2.0, but want to call scs solver.
Is that possible in CVX 2.0?

I am afraid not. However, SDPT3 is not the only other solver you can use on CVX 3.0, either. You could always use SeDuMi, or MOSEK if you have an academic license. So I don’t see a reason to dump CVX 3.0 because of this bug, which is in the SDPT3 connector.

I tried sedumi, however, the error still exists.

Hmm. That doesn’t make sense, because the error posted above is clearly occurring inside the SDPT3 connector. Can you please post the error message you get when you use SeDuMi? Just to be safe, make sure to set the solver to SeDuMi before attempting to run any models at all.

Here is the message of using sedumi

Error using sparse
Index into matrix must be positive.

Error in cvx_sedumi>solve (line 144)
reord = sparse( …

Error in cvx_solve (line 399)
[ x, status, tprec, iters, y ] = shim.solve( At, b, c, cones, params );

Error in cvx_finish (line 57)
[ status, result, bound, iters, tol ] = cvx_solve;

Error in cvx_end (line 11)
evalin( ‘caller’, ‘cvx_finish’ );

Error in Test_CVX (line 45)
cvx_end

If I use sdpt3 or sedumi in CVX 2.1, it works well.
And the message is

Calling SDPT3 4.0: 132 variables, 48 equality constraints
For improved efficiency, SDPT3 is solving the dual problem.

num. of constraints = 48
dim. of sdp var = 35, num. of sdp blk = 6
dim. of free var = 1 *** convert ublk to lblk


SDPT3: Infeasible path-following algorithms


version predcorr gam expon scale_data
HKM 1 0.000 1 0
it pstep dstep pinfeas dinfeas gap prim-obj dual-obj cputime

0|0.000|0.000|3.2e+01|8.2e+00|4.7e+03| 2.240513e+02 0.000000e+00| 0:0:00| chol 1 1
1|0.680|0.491|1.0e+01|4.2e+00|2.3e+03| 1.743712e+02 -5.870694e+01| 0:0:00| chol 1 1
2|0.811|0.653|1.9e+00|1.5e+00|9.3e+02| 1.672635e+02 -1.120657e+02| 0:0:00| chol 1 1
3|0.787|0.505|4.1e-01|7.2e-01|4.8e+02| 1.149914e+02 -1.191803e+02| 0:0:00| chol 1 1
4|1.000|0.948|8.4e-07|3.8e-02|6.0e+01| 3.519316e+01 -1.920072e+01| 0:0:00| chol 1 1
5|1.000|0.362|6.2e-08|2.4e-02|2.2e+01| 5.538987e+00 -1.564702e+01| 0:0:00| chol 1 1
6|0.942|0.947|2.5e-07|1.3e-03|1.4e+00|-6.362228e-01 -2.043432e+00| 0:0:00| chol 1 1
7|1.000|0.737|4.0e-09|3.4e-04|4.0e-01|-1.140173e+00 -1.530622e+00| 0:0:00| chol 1 1
8|1.000|0.349|2.9e-08|2.2e-04|2.3e-01|-1.211408e+00 -1.437252e+00| 0:0:00| chol 1 1
9|1.000|0.321|1.5e-08|1.5e-04|1.6e-01|-1.219253e+00 -1.378559e+00| 0:0:00| chol 1 1
10|1.000|0.580|5.9e-09|6.3e-05|6.8e-02|-1.233052e+00 -1.299383e+00| 0:0:00| chol 1 1
11|1.000|0.687|9.5e-10|2.0e-05|2.0e-02|-1.237635e+00 -1.257749e+00| 0:0:01| chol 1 1
12|1.000|0.434|2.0e-10|1.1e-05|1.1e-02|-1.238658e+00 -1.249689e+00| 0:0:01| chol 1 1
13|1.000|0.480|8.4e-11|5.8e-06|5.7e-03|-1.239174e+00 -1.244712e+00| 0:0:01| chol 1 1
14|1.000|0.526|3.6e-11|2.7e-06|2.6e-03|-1.239391e+00 -1.241945e+00| 0:0:01| chol 1 1
15|1.000|0.557|4.3e-12|7.2e-06|1.1e-03|-1.239483e+00 -1.240580e+00| 0:0:01| chol 1 1
16|1.000|0.968|5.7e-14|3.1e-06|4.0e-05|-1.239507e+00 -1.239544e+00| 0:0:01| chol 1 1
17|0.986|0.987|3.3e-14|1.1e-07|5.3e-07|-1.239511e+00 -1.239512e+00| 0:0:01| chol 1 1
18|0.993|0.989|9.8e-15|1.4e-09|1.2e-08|-1.239511e+00 -1.239511e+00| 0:0:01|
stop: max(relative gap, infeasibilities) < 1.49e-08

number of iterations = 18
primal objective value = -1.23951149e+00
dual objective value = -1.23951150e+00
gap := trace(XZ) = 1.15e-08
relative gap = 3.31e-09
actual relative gap = 3.09e-09
rel. primal infeas (scaled problem) = 9.80e-15
rel. dual " " " = 1.44e-09
rel. primal infeas (unscaled problem) = 0.00e+00
rel. dual " " " = 0.00e+00
norm(X), norm(y), norm(Z) = 5.3e+00, 1.7e+00, 7.3e+00
norm(A), norm(b), norm© = 1.4e+01, 3.6e+00, 7.1e+00
Total CPU time (secs) = 0.61
CPU time per iteration = 0.03
termination code = 0
DIMACS: 1.8e-14 0.0e+00 3.4e-09 0.0e+00 3.1e-09 3.3e-09


Status: Solved
Optimal value (cvx_optval): +1.23951

I have to admit, I’m stumped. I ran your problem without incident using both SeDuMi and SDPT3 on my machine with CVX 3.0.

The only thing I can think of is that there are some M-files in your MATLAB path with names that conflict with variables in these CVX functions. But the fact that CVX 2.1 works fine suggests that may not be the issue.

I’m afraid I do not have a solution for you, and you will have to stick with CVX 2.1 unless you can diagnose it yourself.

Thank you for your suggestion

Could it be that lsjxjtu’s path is in a different order with CVX 3.0 vs. 2.1?

Sorry, I didn’t get your point. What does it mean?

I go back to track the cvx code. I found that the variable 'cones.indices’
in FUNCTION ‘cvx_extract’ (lines 339 - 342) might have zero values.
It should not be correct, right? Since indices must be positive values.

That’s a good find. No, ‘cones.indices’ should not have zero values. That would explain why both SeDuMI and SDPT3 are seeing the issue. Thus the problem is earlier in the code. But I’m not seeing that issue here when I run your model with either solver.

As reply to mcg, I was suggesting the possibility that “CVX” could be in a different location in your MATLAB path for your 3.0 installation than your 2.1 installation. And therefore you could be getting a name conflict in 3.0 but not in 2.1 (even if on the same machine).

I suppose folks, including myself, have been assuming your 3.0 and 2.1 installations were on the same computer (at different times) when they were installed, but is that even the case? Did you actually install 3.0 on a different machine than 2.1, where there could be all sorts of other differences?

Actually, when I installed CVX 3.0 I removed CVX 2.1 first. In that case, is there still a conflict?

When you change the parameter alpha, my model works very well every time in your computer?
If that is true, I could try CVX in a different computer to void the possible issue of installation.

I was suggesting you look at MATLAB path both with 3.0 when getting the error and 2.1 when not getting the error and check that they are the same (except CVX items being 3.0 vs. 2.1).

Changing the value of alpha doesn’t cause an error. I tried 0, 0.001, 0.01, 0.1, 0.9.

Yes, it is important to emphasize that if there are any traces of CVX 2.1 accessible to MATLAB when running CVX 3.0, weird things could happen.