Matlab OUT OF MEMORY error on optimization problem

1

Hi all, I’m running a Matlab to resolve an optimization problem with CVX, and at a certain point, it throws a

Out of memory. Type HELP MEMORY for your options.

Error in cvx_reshape (line 41)
        x = sparse( ii, jj, x, s( 1 ), s( 2 ) );

Error in  *  (line 188)
    z2 = cvx_reshape( z2, [ nA, nz ], tt );

Error in laplacian_learning (line 86)
            Objective = trace(Sk'*Ck*Sk) + param.mu* norm(L_recovered,'fro')

This is the CVX code:

   cvx_clear
    cvx_begin quiet
        variable L_recovered(param.N,param.N) semidefinite
        variable Ck(param.K,param.K) semidefinite

        Objective = trace(Sk'*Ck*Sk) + param.mu* norm(L_recovered,'fro')
        minimize Objective
        subject to
            L_recovered*Uk==Uk*Ck
            L_recovered*ones(param.N,1)==zeros(param.N,1)               
            triu(L_recovered,1)<=0; % off diagonal <=0
            diag(L_recovered)>=0;
            trace(L_recovered)==trace_constraint;
    cvx_end

The Objective is a CVX object and: Sk is a 64x400 matrix, Ck is a 64x64 matrix and L_recovered is a 76x76 matrix and is the variable I want to learn through the optimization problem together with Ck.
My PC has 8 GB of RAM DDR3, and an Intel i3 (I know…) … but the problem I think is the RAM. Which step should I follow to resolve this problem?
Thank you in advance

EDIT: I tried also with a 16GB RAM DDR3. Before the solver is called, MATLAB reachs 16GB of RAM and a bit later, it throws the OUT OF MEMORY error, due to the sparse and cvx_reshape functions of CVX.

2

I’m presuming Ck iand L_recovered are CVX variables. If they are not symmetric, and are real, tey total 9872 variables, leaving aside whatever else you have. Can you try a smaller version of the problem and see what the memory usage is and how it scales as the dimension is increased?

I will have to defer to someone else to help you, because it appears that the error is occurring before the solver is called. Therefore, i don’t know that switching from a second order solver to a first order solver such as SCS or SuperSCS (both only available under CVX 3.0BETA, which unfortunately has many bugs) is going to help at all.

Maybe (maybe!!) someone could offer some suggestions if you provided a complete formulation.

3

Hi Mark, thank you for your reply.
I have edited my questions, where I added the CVX code. As you can see both the variables are semidefinite positive and hence symmetric. Until now, this code correctly does his work on synthetic data with matrix of dimension 32x100. Now when working with real data and matrix 76x400 it doesn’t work.
Do you recommend me to try with CVX 3.0? In such a case, should I delete the older version of CVX?

4

You can try CVX 3.0BETA, but I am not recommending it due to its many bugs. But I am not recommending you don’t try it.

To install CVX 3.0BETA, first remove all CVX directories (folders) from the MATLAB path and save the path. Then start a new MATLAB session and install CVX 3.0BETA using cvx_setup .

As I wrote before, CVX 3.0BETA using SCS or SuperSCS might help if the OUT OF MEMORY occurred while the solver was executing. But apparently it is occurring during execution of the Objective statement. What happens if you put the constraints before Objective - are they accepted without OUT OF MEMORY message?

Can you look at the individual terms of Objective and see which are causing difficulty? My guess is that trace(Sk'*Ck*Sk) may be a more likely culprit than the norm term. You could maybe simplify the trace term by doing

variable Ck_chol(param.K,param.K) upper_triangular
V = vec(Ck_chol * S);
Objective = V' * V  + param.mu* norm(L_recovered,'fro')

But I don’t see how you could incorporate the constraint L_recovered*Uk==Uk*Ck, which would become L_recovered*Uk==Uk*Ck_chol'*Ck_chol, (and never declare Ck) which is not allowed under the DCP rules (including under CVX 3.0BETA).

A semidefinite relaxation could be accomplished with the following (but you should check to make sure i didn’t make any mistakes)

variable Ck(param.K,param.K) symmetric
variable Ck_chol(param.K,param.K) upper_triangular
V = vec(Ck_chol * S);
Objective = V' * V  + param.mu* norm(L_recovered,'fro')
[Ck Ck_chol';Ck_chol eye(param.K] == semidefinite(2*param.K)
L_recovered*Uk==Uk*Ck

But I have no reason to believe that Ck = Ck_chol' * Ck_chol will hold at the optimum. But if it does, your original problem has been solved. Note however that I don’t even know that this formulation requires less memory for CVX to formulate or the solver to solve.

Maybe a more capable reader can come up with a useful reformulation.

If you do get to the point that CVX will accept your program and call the solver, and the solver runs out of memory, then calling SuperSCS (or SCS) under CVX3.0BETA may help, although CVX3.0BETA is buggy.

`

5

From what I see, I made an error in the question… I said that Sk is a 64x64. That’s not true, it is a 64x400 matrix. In this way

Sk’ * Ck* Sk
is a 400x400 matrix. But I could replace that term with a cyclic

Sk Sk’ Ck

which is a 64x64 term. Moreover I have Sk before launching the cvx problem, if it can help me (for example by preallocating the product SkSk’).
Moreover, you said I can try to put constraints before objective… do you intend to place the subject to statement before objective (I didn’t know it would be possible). I didn’t understand when you write

[Ck Ck_chol’;Ck_chol eye(param.K] == semidefinite(2param.K)
L_recoveredUk==Uk*Ck

Where do you specificy the coupling between Ck and Ck_chol?

6

Well, if your cyclic permutation resolves the OUT OF MEMORY, just do that.

trace((SK*Sk’)*Ck) will be the smae to CVX as pre-computng Sk;*Sk (note that my previous post used S for what you had written as Sk).

Constraints can appear anywhere between cvx_begin and cvx_end, provided they are after declaration of variables and expressions and expression assignments which they use. “subject to” is a placebo statement - it does nothing and is not needed, and is made available merely to make the program easier to read or understand - I never use it myself - I idon’t need no stinking placebo statements.

I was suggesting changing the order of statements just for you to diagnose what was contributing to OUT OF MEMORY. Have you been issuing the statements one at a time and observe OUT OF MEMORY when you enter the Objective statement?

As for the semideifnite relaxation,
[Ck Ck_chol';Ck_chol eye(param.K] == semidefinite(2*param.K)
provides a relaxed coupling between Ck and Ck_chol. The difficulty is that it might not be tight at the optimum, in which case you would not have solved the original problem. Given your corrected information on dimensions, I doubt the semidefinite relaxation has any merit vs. the cyclic trace permutation, although I guess it is still possible it could due to Ck_chol being upper triangular.

7

That resolved! (even if the results is not as expected, but this is another problem)… I don’t know why the trace terms was a problem before, for a 400x400 matrix, in a 16GB ram PC. Do you have any idea?
However I also placed the constraint before, but in this case all gone well.
Thank you again :slight_smile:

PS: for certain values of \mu, the regularization parameter, I note how the optimal_value given by CVX is +INF and status infeasible; other times NaN, altough the variables are correcly learned. What does it mean?

8

Perhaps some of your \mu values are so high that the problem is numerically challenging. It may be possible that very large coefficients, such as \mu (param.mu), get coupled into the constrains either by pre-solve, or in this case with CVX, the norm term in the objetive is reformualed internally by CVX into a Second Order Cone constraint by epigraph formulatio. Numerical disparity with other constraints could make the problem appear to the solver to be infeasible, even though in exact arithmetic (which solvers do not use), changing the value of \mu can not change the feasibility of the problem.

Which solver(s) are you using? Of th4e solvers available under CVX to solve semidefinite problems such as yours, Mosek should be the most trustworthy and robust - however, it is quite possible to provide numerical inputs which cause difficulties.

My number one recommendation is to remove the quiet option. Then you can see the output from the solver, to include warning messages, among other data. The Mosek guys on this forum may be able to give you advice depending on what the output shows for Mosek, and maybe even for other solvers.

9

Currently I’m using SDPT3 and I don’t have Mosek, but I could ask a license for academic purposes if the case it could improve my performance (EDIT: I installed and at the bottom of the page there is the Mosek output). By the way, this is the output by the solver without the quit option, if it could help… do you see any strange?

The variables learned are filled with NaN.

> Objective =
>  
>     cvx convex expression (scalar)
>  
>  
> Calling SDPT3 4.0: 18651 variables, 5007 equality constraints
>    For improved efficiency, SDPT3 is solving the dual problem.
> ------------------------------------------------------------
> 
>  num. of constraints = 5007
>  dim. of sdp    var  = 140,   num. of sdp  blk  =  2
>  dim. of socp   var  = 5778,   num. of socp blk  =  1
>  dim. of linear var  = 2926
>  dim. of free   var  = 4941 *** 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|5.2e+02|1.0e+02|1.4e+16|-1.898218e+01  0.000000e+00| 0:0:07| chol  2  2 
>  1|0.593|0.212|2.1e+02|8.1e+01|5.6e+15| 4.975143e+12 -6.657295e+10| 0:0:13| chol  2  2 
>  2|0.915|0.847|1.8e+01|1.3e+01|6.9e+14| 7.025938e+12 -5.748055e+10| 0:0:20| chol  2  2 
>  3|0.849|0.954|2.7e+00|7.0e-01|4.0e+13| 4.426220e+12 -5.389540e+09| 0:0:27| chol  2  2 
>  4|0.883|0.712|3.2e-01|2.5e-01|1.2e+13| 1.464284e+12 -3.416735e+09| 0:0:36| chol  2  2 
>  5|0.257|0.266|2.4e-01|1.9e-01|8.5e+12| 1.161418e+12 -4.435727e+09| 0:0:45| chol  2  2 
>  6|0.301|0.498|1.7e-01|1.0e-01|4.7e+12| 9.607910e+11 -5.096513e+09| 0:0:55| chol  2  2 
>  7|0.408|0.227|9.8e-02|8.1e-02|3.4e+12| 7.555681e+11 -4.723005e+09| 0:1:08| chol  2  2 
>  8|0.346|0.251|6.4e-02|6.8e-02|2.7e+12| 6.204201e+11 -4.947352e+09| 0:1:14| chol  2  2 
>  9|0.615|0.236|2.5e-02|5.8e-02|2.0e+12| 4.360755e+11 -4.777416e+09| 0:1:21| chol  2  2 
> 10|0.640|0.299|8.9e-03|4.5e-02|1.3e+12| 2.964462e+11 -4.974654e+09| 0:1:29| chol  2  2 
> 11|0.472|0.286|4.7e-03|3.4e-02|9.6e+11| 2.148697e+11 -4.911948e+09| 0:1:37| chol  2  2 
> 12|0.447|0.171|2.6e-03|3.7e-02|8.5e+11| 1.466145e+11 -4.965557e+09| 0:1:48| chol  2  2 
> 13|0.690|0.378|8.0e-04|2.4e-02|5.3e+11| 6.892453e+10 -4.882686e+09| 0:1:56| chol  2  2 
> 14|0.527|0.280|3.8e-04|1.7e-02|3.9e+11| 2.318568e+10 -4.900800e+09| 0:2:06| chol  2  2 
> 15|0.506|0.246|1.9e-04|1.3e-02|3.2e+11|-8.260972e+09 -4.901525e+09| 0:2:12| chol  2  2 
> 16|0.364|0.292|1.2e-04|9.3e-03|2.4e+11|-2.378731e+10 -5.057136e+09| 0:2:20| chol  2  2 
> 17|0.310|0.160|8.2e-05|1.0e-02|3.0e+11|-4.042965e+10 -5.361595e+09| 0:2:35| chol  2  2 
> 18|0.432|0.297|4.7e-05|7.4e-03|2.4e+11|-6.087730e+10 -5.614959e+09| 0:2:42| chol  2  2 
> 19|0.308|0.221|3.2e-05|5.8e-03|2.2e+11|-8.687520e+10 -5.720328e+09| 0:2:49| chol  2  2 
> 20|0.240|0.156|2.5e-05|6.7e-03|3.3e+11|-1.239428e+11 -5.845926e+09| 0:2:58| chol  2  2 
> 21|0.470|0.191|1.3e-05|7.4e-03|5.7e+11|-1.997490e+11 -5.944463e+09| 0:3:05| chol  2  2 
> 22|0.636|0.332|4.8e-06|4.9e-03|5.1e+11|-3.356002e+11 -6.048381e+09| 0:3:13| chol  2  2 
> 23|0.490|0.229|2.4e-06|3.8e-03|6.2e+11|-6.945431e+11 -6.113602e+09| 0:3:22| chol  2  2 
> 24|0.214|0.146|1.9e-06|4.7e-03|1.6e+12|-1.304990e+12 -6.148676e+09| 0:3:30| chol  2  2 
> 25|1.000|0.233|1.1e-10|3.6e-03|3.2e+12|-4.510126e+12 -6.163643e+09| 0:3:38| chol  2  2 
> 26|0.312|0.172|2.7e-10|4.4e-03|1.2e+13|-1.174352e+13 -6.195181e+09| 0:3:47| chol  2  2 
> 27|1.000|0.196|1.4e-09|5.1e-03|6.4e+13|-4.653126e+13 -6.215491e+09| 0:3:56| chol  2  2 
> 28|1.000|0.168|5.2e-09|6.0e-03|2.7e+14|-1.442498e+14 -6.321301e+09| 0:4:04| chol * 3 * 3 
> 29|1.000|0.240|1.9e-08|4.6e-03|4.2e+14|-3.593101e+14 -6.835959e+09| 0:4:17| chol * 3 * 3 
> 30|1.000|0.222|4.4e-08|3.5e-03|8.8e+14|-1.319637e+15 -7.486530e+09| 0:4:26|
>   stop: progress is too slow
>   prim_inf,dual_inf,relgap = 4.41e-08, 3.54e-03, 6.69e-01
>   sqlp stop: dual problem is suspected of being infeasible
> -------------------------------------------------------------------
>  number of iterations   = 30
>  residual of dual infeasibility        
>  certificate X          = 1.46e-06
>  reldist to infeas.    <= 3.38e-10
>  Total CPU time (secs)  = 266.03  
>  CPU time per iteration = 8.87  
>  termination code       =  2
>  DIMACS: 2.6e-07  0.0e+00  5.0e-03  0.0e+00  -1.0e+00  6.7e-01
> -------------------------------------------------------------------
>  
> ------------------------------------------------------------
> Status: Infeasible
> Optimal value (cvx_optval): +Inf

EDIT
EDIT
EDIT: I also installed Mosek and made a try… but nothing good… this is the Mosek output

Calling Mosek 8.0.0.60: 18651 variables, 5007 equality constraints
   For improved efficiency, Mosek is solving the dual problem.
------------------------------------------------------------

MOSEK Version 8.0.0.60 (Build date: 2017-3-8 15:53:11)
Copyright (c) MOSEK ApS, Denmark. WWW: mosek.com
Platform: Linux/64-X86

MOSEK warning 52: A numerically large lower bound value  2.6e+08 is specified for constraint '' (0).
MOSEK warning 53: A numerically large upper bound value  2.6e+08 is specified for constraint '' (0).
MOSEK warning 52: A numerically large lower bound value -2.1e+08 is specified for constraint '' (2).
MOSEK warning 53: A numerically large upper bound value -2.1e+08 is specified for constraint '' (2).
MOSEK warning 52: A numerically large lower bound value -3.2e+08 is specified for constraint '' (3).
MOSEK warning 53: A numerically large upper bound value -3.2e+08 is specified for constraint '' (3).
MOSEK warning 52: A numerically large lower bound value -2.8e+08 is specified for constraint '' (4).
MOSEK warning 53: A numerically large upper bound value -2.8e+08 is specified for constraint '' (4).
MOSEK warning 52: A numerically large lower bound value  1.5e+08 is specified for constraint '' (5).
MOSEK warning 53: A numerically large upper bound value  1.5e+08 is specified for constraint '' (5).
MOSEK warning 52: A numerically large lower bound value  1.5e+08 is specified for constraint '' (6).
MOSEK warning 53: A numerically large upper bound value  1.5e+08 is specified for constraint '' (6).
MOSEK warning 52: A numerically large lower bound value  1.1e+08 is specified for constraint '' (8).
MOSEK warning 53: A numerically large upper bound value  1.1e+08 is specified for constraint '' (8).
MOSEK warning 52: A numerically large lower bound value -1.8e+08 is specified for constraint '' (11).
MOSEK warning 53: A numerically large upper bound value -1.8e+08 is specified for constraint '' (11).
MOSEK warning 52: A numerically large lower bound value -2.2e+08 is specified for constraint '' (15).
MOSEK warning 53: A numerically large upper bound value -2.2e+08 is specified for constraint '' (15).
MOSEK warning 52: A numerically large lower bound value  1.9e+08 is specified for constraint '' (19).
MOSEK warning 53: A numerically large upper bound value  1.9e+08 is specified for constraint '' (19).
Warning number 52 is disabled.
Warning number 53 is disabled.
Problem
  Name                   :                 
  Objective sense        : min             
  Type                   : CONIC (conic optimization problem)
  Constraints            : 5007            
  Cones                  : 1               
  Scalar variables       : 13645           
  Matrix variables       : 2               
  Integer variables      : 0               

Optimizer started.
Conic interior-point 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.03            
Lin. dep.  - number                 : 0               
Presolve terminated. Time: 0.24    
Optimizer  - threads                : 2               
Optimizer  - solved problem         : the primal      
Optimizer  - Constraints            : 5007
Optimizer  - Cones                  : 2
Optimizer  - Scalar variables       : 13646             conic                  : 10720           
Optimizer  - Semi-definite variables: 2                 scalarized             : 5006            
Factor     - setup time             : 5.31              dense det. time        : 0.00            
Factor     - ML order time          : 2.41              GP order time          : 0.00            
Factor     - nonzeros before factor : 1.25e+07          after factor           : 1.25e+07        
Factor     - dense dim.             : 4                 flops                  : 4.20e+10        
ITE PFEAS    DFEAS    GFEAS    PRSTATUS   POBJ              DOBJ              MU       TIME  
0   6.3e+05  1.0e+00  1.0e+00  0.00e+00   0.000000000e+00   0.000000000e+00   1.0e+00  5.82  
1   3.7e+05  5.9e-01  4.6e-01  -1.00e+00  7.597110713e+04   2.548571366e+05   5.9e-01  10.20 
2   2.5e+03  3.9e-03  2.5e-04  -1.00e+00  3.102138797e+07   9.802335256e+07   3.9e-03  15.31 
3   4.6e-01  7.3e-07  9.4e-10  -1.00e+00  7.703927282e+10   2.432561882e+11   7.3e-07  18.94 
4   6.4e-02  1.0e-07  9.2e-10  8.60e-01   2.810161408e+10   3.134478611e+10   1.0e-07  23.09 
5   2.8e-02  4.6e-08  2.3e-09  4.00e+00   3.868990448e+09   3.968931881e+09   4.5e-08  27.34 
6   1.5e-02  2.4e-08  1.9e-09  2.53e+00   9.473874964e+08   9.887598755e+08   2.4e-08  34.63 
7   1.9e-03  3.1e-09  4.8e-10  1.24e+00   -9.327435425e+08  -9.217869481e+08  3.0e-09  39.68 
8   8.0e-04  1.3e-09  2.3e-10  7.53e-02   -1.586868818e+09  -1.578829545e+09  1.3e-09  43.27 
9   4.3e-04  6.9e-10  1.5e-10  2.57e-01   -2.110241133e+09  -2.104541402e+09  6.8e-10  47.08 
10  2.3e-04  3.7e-10  8.9e-11  3.02e-01   -2.603901903e+09  -2.599508816e+09  3.6e-10  51.63 
11  1.2e-04  1.9e-10  4.7e-11  1.59e-01   -3.051466784e+09  -3.047040970e+09  1.9e-10  56.48 
12  7.6e-05  1.2e-10  3.0e-11  -5.73e-02  -3.366524196e+09  -3.361943230e+09  1.2e-10  61.55 
13  3.7e-05  6.1e-11  1.3e-11  -2.01e-01  -3.949929541e+09  -3.944501948e+09  5.9e-11  66.02 
14  6.4e-06  1.0e-11  1.1e-12  -5.54e-01  -5.497769117e+09  -5.474579082e+09  1.0e-11  70.47 
15  8.8e-07  1.4e-12  6.8e-14  -9.59e-01  -5.030768579e+09  -4.915108938e+09  1.4e-12  73.99 
16  1.7e-08  2.6e-14  1.7e-16  -9.83e-01  -1.460607146e+10  -8.678183035e+09  2.5e-14  78.00 
17  3.5e-08  7.1e-13  5.0e-16  -1.00e+00  -1.316266257e+01  -4.541216252e+00  1.4e-18  82.78 
Interior-point optimizer terminated. Time: 82.82. 

Optimizer terminated. Time: 82.94   

Interior-point solution summary
  Problem status  : ILL_POSED
  Solution status : DUAL_ILLPOSED_CER
  Primal.  obj: -1.3162662566e+01   nrm: 2e+04    Viol.  con: 2e-05    var: 0e+00    barvar: 0e+00    cones: 0e+00  
Optimizer summary
  Optimizer                 -                        time: 82.94   
    Interior-point          - iterations : 17        time: 82.82   
      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: Failed
Optimal value (cvx_optval): NaN
10

Mosek is very clearly warning you about the value 2e8… Is that the value of param.mu you used? That apparent;y makes the problem excxessivley ill-conditioned to handle reliably.

See my posts in Prescribing tolerance for positivedefiniteness for how to get CVX to use the Mosek version you installed instead of the old version, 8.0.0.80, provided in the CVX installation. Perhaps the latest 8.1 or 9.0 beta version will be able to better deal with your numerically challenging problemr than 8.0.0.80. But in any event, try to keep the value of param.mu smaller.

11

Mark, I’m using a param.mu={10,100}… by changing the matrix Sk or by changing param.mu, the problem could be feasible or not feasible depending on the case. What Mosek is trying to say to me when
MOSEK warning 52: A numerically large lower bound value 1.5e+08 is specified for constraint ‘’ (5).
MOSEK warning 53: A numerically large upper bound value 1.5e+08 is specified for constraint ‘’ (5).

?
The constraint number to which refers to?

12

MOSEK is referring to the problem as provided by CVX. But CVX transforms the problem you enter to create the inputs provided to MOSEK. I don’t know what the correspondence would be between the problem as you entered it into CVX and what is provided to MOSEK.

Do you see any number such as 1.5e+08 in your inputs to CVX? But perhaps that 1.5e+08 represents some transformation by CVX, and maybe even by MOSEK. I will defer to @Erling , @Michal_Adamaszek ,or @hfriberg for any additional diagnosis or help with what MOSEK is doing. I presume they would like to see a complete reproducible problem in order to give the most specific assessment.

Edit: Also, you haven’t given us any idea what magnitude numbers are in the matrix S. (a.k.a. Sk). What are the smallest and largest magnitude non-zero numbers in S ? Are any of them 1.5e+08, for example, or very small magnitude, at least for the problem instances in which the problem is reported infeasible?

13

You are right, Sk values have ranges in [-2000 , +3000] circa. However the mean values is about 3.5… if this can help

14

What are the smallest magnitude non-zero numbers in Sk?

15

About 0.06, this could create some problem in the trace term maybe …

16

Can you please remove the objective, solve it with Mosek, and show all solver output? Then we should know whether the problem is really feasible without the "“distraction” caused by large numbers in the objective function. This true feasibility will hold regardless of the values of Sk and param.mu when the objective is included.

17

When MOSEK prints constraint index etc. out then it corresponds to the model it has. Hence it may be hard to relate that back to CVX.

18

Sorry for the late reply, I noted that standardizing the data (a pre-processing step) helps the algorithm to not reach the infeasibility and I should investigate more on this. Thus Mark, since my schedules are tight, I deserve to test this behavior in future. Thank you so much for your opening.
Thank you Erling also for your comment.
I’m now in troubles with the following quadratic form, that CVX doesn’t like since it is not a scalar:

Sigma= diag(sigma*ones(N,1))
Sigma_inv= inv(Sigma);
cvx_begin
variable d(N)
D= diag(d)
B= Uk'*D*Sigma_inv* D*Uk;
maximize -lambda_min(B)

Where Uk is a NxK matrix. Can you help me in rewriting this in form accepted by cvx? Should I open another thread?

19

If B were affine, which it is not, the objective function -lambda_min(B)would be convex, and therefore maximizing it would be non-convex. So you either need to formulate a provably convex optimization problem, or use a different tool for this problem.

If you wish to pursue this further, please open a new thread. It becomes confusing when more than one problem is addressed in a given thread, unless perhaps they are closely related.

1 Like
20

Yes sure, it’s less confusing. Thank you again :slight_smile: