CVXPY feasible problem found infeasible in CVX

1

I am running the below optimisation problem using CVX with matlab R2024b:


maxLambda=2.82404;  
minLambda=-0.993162;

m=1;
r=0.412019;

%for k=1:size(Ts,2)
[xi,N,epsilon,s,sp] = deal(0.001,1e11,2^(-104),104,51);
[mu, xth, Psig, Ptest] = deal(0.4741,.4640,.8569,.1339); %ok
T=10^(-.5/10);
beta=sqrt(T*mu); %ok
q=(1 - exp(-2*mu)) / 2; %ok ok

cvx_begin
    cvx_precision low
    cvx_solver Mosek
    cvx_solver_settings('MSK_IPAR_LOG', 1) 
    
    variable ball_var(1,2) nonnegative
    kap=ball_var(1) 
    gam=ball_var(2) 
    
    Nt = N*(1-Psig-Ptest);

    [a,b,c,d,e,f]=deal(.7148,.2852,.8874,.5665,.0999,.2456);

    M1 =[   1          sqrt(e)           0             0;...
            sqrt(e)      kap*a+c      kap*sqrt(a*b)      0;...
                0        kap*sqrt(a*b)  kap*b+d-gam   sqrt(f);...
                0             0            sqrt(f)       1-gam];

    M2 =[    kap*b        kap*sqrt(a*b);...
          kap*sqrt(a*b)    kap*a-gam];

    B = max([lambda_max(M1), lambda_max(M2), 1]);    

    [Psuc,Hec]=deal(.5638,8.6735e+09); %should be ok

    delt2 = 1.7576e+06; % should be ok
    
    Cmin = min([(1/Ptest)*kap*minLambda,   -(1/(1-Psig-Ptest))*gam, 0]);
    Cmax = max([(1/Ptest)*kap*maxLambda,   1/Psig, 0]);
    delt1=(Cmax-Cmin)*sqrt((N/2)*log(1/epsilon));
    
    F=1.3382e+10; %ok ok
    Ptrash = 1-(Psig+Ptest);
    UF = -kap*(Psig/Ptest)*F +...
            gam*(Psig/Ptrash)*(Nt*q+delt2) +...
            Psig*(N*B+delt1);

    minimise UF

cvx_end
disp(kap)
disp(gam)

Although I have access to a CVXPY version of the problem (that uses Mosek as well) that manages to find a (strictly positive) solution, and I could verify that my formulas work as intended on the values of kap and gam found by the “Python x CVXPY” implementation.
However, running the above returns the following:

 
kap =
 
    cvx real affine expression (scalar)
 
 
gam =
 
    cvx real affine expression (scalar)
 
 
Calling Mosek 9.1.9: 24 variables, 7 equality constraints
   For improved efficiency, Mosek is solving the dual problem.
------------------------------------------------------------
NOTE: custom settings have been set for this solver.
------------------------------------------------------------

MOSEK Version 9.1.9 (Build date: 2019-11-21 11:27:13)
Copyright (c) MOSEK ApS, Denmark. WWW: mosek.com
Platform: Linux/64-X86

MOSEK warning 52: A numerically large lower bound value -8.6e+10 is specified for constraint '' (2).
MOSEK warning 53: A numerically large upper bound value -8.6e+10 is specified for constraint '' (2).
MOSEK warning 52: A numerically large lower bound value  2.6e+10 is specified for constraint '' (3).
MOSEK warning 53: A numerically large upper bound value  2.6e+10 is specified for constraint '' (3).
MOSEK warning 52: A numerically large lower bound value  8.6e+10 is specified for constraint '' (4).
MOSEK warning 53: A numerically large upper bound value  8.6e+10 is specified for constraint '' (4).
Problem
  Name                   :                 
  Objective sense        : min             
  Type                   : CONIC (conic optimization problem)
  Constraints            : 7               
  Cones                  : 1               
  Scalar variables       : 14              
  Matrix variables       : 1               
  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.00    
Problem
  Name                   :                 
  Objective sense        : min             
  Type                   : CONIC (conic optimization problem)
  Constraints            : 7               
  Cones                  : 1               
  Scalar variables       : 14              
  Matrix variables       : 1               
  Integer variables      : 0               

Optimizer  - threads                : 10              
Optimizer  - solved problem         : the primal      
Optimizer  - Constraints            : 6
Optimizer  - Cones                  : 1
Optimizer  - Scalar variables       : 12                conic                  : 3               
Optimizer  - Semi-definite variables: 1                 scalarized             : 10              
Factor     - setup time             : 0.00              dense det. time        : 0.00            
Factor     - ML order time          : 0.00              GP order time          : 0.00            
Factor     - nonzeros before factor : 16                after factor           : 18              
Factor     - dense dim.             : 0                 flops                  : 4.74e+02        
ITE PFEAS    DFEAS    GFEAS    PRSTATUS   POBJ              DOBJ              MU       TIME  
0   8.6e+10  1.2e+00  1.5e+00  0.00e+00   -1.898516069e+06  -1.898516615e+06  1.0e+00  0.00  
1   1.7e+10  2.3e-01  6.9e-01  -1.00e+00  -1.898509648e+06  -1.898506155e+06  2.0e-01  0.00  
2   4.9e+09  6.7e-02  2.8e+04  -1.00e+00  -1.898492176e+06  -2.012999644e+06  5.8e-02  0.00  
3   1.3e+09  1.8e-02  1.7e+04  -1.00e+00  -1.898440409e+06  -2.038928332e+06  1.5e-02  0.00  
4   1.5e+08  2.1e-03  2.4e+03  -1.00e+00  -1.897992583e+06  -1.840054137e+06  1.8e-03  0.00  
5   3.0e+07  4.1e-04  1.3e+03  -1.00e+00  -1.897132265e+06  -1.824012790e+06  3.5e-04  0.00  
6   9.3e+06  1.3e-04  8.6e+02  -1.00e+00  -1.890549522e+06  -1.798415941e+06  1.1e-04  0.00  
7   1.8e+06  2.5e-05  3.4e+02  -1.00e+00  -1.827046336e+06  -1.705955451e+06  2.1e-05  0.00  
8   8.2e+04  1.1e-06  5.1e+01  -1.00e+00  5.974835733e+04   1.159624042e+06   9.5e-07  0.00  
Optimizer terminated. Time: 0.00    


Interior-point solution summary
  Problem status  : PRIMAL_INFEASIBLE
  Solution status : PRIMAL_INFEASIBLE_CER
  Dual.    obj: 2.9202127947e+00    nrm: 3e-02    Viol.  con: 0e+00    var: 8e-07    barvar: 1e-06    cones: 0e+00  
Optimizer summary
  Optimizer                 -                        time: 0.00    
    Interior-point          - iterations : 8         time: 0.00    
      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: Unbounded
Optimal value (cvx_optval): -Inf
 
   1.1562e-04

   2.5083e-06

I fail to understand what is blocking CVX.
Also, although the two values “kap= 1.1562e-04” and “gam=2.5083e-06” returned by the program are probably not that relevant considering CVX sees the problem as unfeasible, running the program for those values of kap and gam finds “UF = 1.1346e+11”.

I did try to use other solvers (SDPT3 and SeDuMi), but they also deemed the problem infeasible.

I however cannot provide the “Python x CVXPY” implementation.

In case it plays a role, here is the output of cvx_setup:

---------------------------------------------------------------------------
CVX: Software for Disciplined Convex Programming       (c)2014 CVX Research
Version 2.2, Build 1148 (62bfcca)                  Tue Jan 28 00:51:35 2020
---------------------------------------------------------------------------
Installation info:
    Path: /usr/local/MATLAB/R2024b/toolbox/cvx
    MATLAB version: 24.2 (R2024b)
    OS: Linux amd64 version 6.8.0-124-generic
    Java version: 1.8.0_202
Verfying CVX directory contents:
    WARNING: The following files/directories are missing:
        /usr/local/MATLAB/R2024b/toolbox/cvx/sedumi/.travis.yml
    These omissions may prevent CVX from operating properly.
Preferences: 
    Path: /home/#############/.matlab/cvx_prefs.mat
License host:
    Username: ################################
    Host ID: #################################
Installed license:
    No license installed.
No valid licenses found.
    Click here to fill out an academic license request
    for the username and first hostid listed above.
---------------------------------------------------------------------------
Setting CVX paths...done.
Saving updated path...failed. (see below)
Searching for solvers...5 shims found.
3 solvers initialized (* = default):
    Mosek    9.1.9      {cvx}/mosek/a64
 *  SDPT3    4.0        {cvx}/sdpt3
    SeDuMi   1.3.4      {cvx}/sedumi
2 solvers skipped:
    GLPK                
        Could not find a GLPK installation.
    Gurobi   unknown    {cvx}/gurobi/a64
        No valid Gurobi license was found.
1 solver issued warnings:
    Mosek    9.1.9      {cvx}/mosek/a64
        Using MOSEK with CVX requires an academic MOSEK license
        or a MOSEK-enabled CVX Professional license. Commercial
        users with MOSEK licenses should contact sales@cvxr.com.
Saving updated preferences...done.
Testing with a simple model...done!
2

You are using an old Mosek 9, use the latest one:

Most likely in CVXPY you are using a more recent one, which could explain the major part of the difference.

You get many warnings about bad scaling. This can also contribute to your problem being borderline feasible/infeasible/unbounded and sometimes tipping one way or another depending on the model and the solver’s mood.

In any case getting identical results from two different models on two different platforms is almost impossible, so you shouldn’t expect bit for bit identical results.

By the way, Mosek does not think your problem is infeasible, but unbounded.

1 Like
3

You haven’t provided a reproducible problem in CVX, and you haven’t shown us your CVYPY code or output.

But I note the following, Mosek provided warnings about large magnitude input data. Therefore, the results, such as feasibility (actually unboundedness determination ,because Mosek determined primal infeasibility, but it was provided the dual of the problem by CVX, so that corresponds to unboundeness in your original problem as entered in CVX), might not be reliable. Also, you should not use cvx_precision low Just leave cvx_precision at its default. cvx_precision was a well-intentioned but counterproductive feature as we now know. I don’t know whether cvx_precision low affected the results in this case, but it is better to not have it.

Moreover, you are using Mosek 9.1.9, which is a very old version of Mosek which came prepackaged with CVX 2.2. You can download the latest stable version of Mosek (11.2.2 as of this writing) and re-run cvx_setup, and then choose the new version of Mosek as the solver using cvx_solver. But you might as well download and install CVX 2.2.2 from Release 2.2.2 · cvxr/CVX · GitHub .

I don’t know what version of Mosek was called when using CVXPY, but ideally, you should use the same (latest stable) version as for CVX. The current version of Mosek is more numerically reliable than Mosek 9.1.9. So everything else equal, you should trust it more. But no matter what, you should rescale your data (choose different input units) so that non-zero input data is within a small number of orders of magnitude of 1, and certainly such that Mosek does not issue any warning messages.

Edit: @Michal and I replied at the same time. You can use the union of out posts.

1 Like
4

Thank you for your answers!

The main difference between my CVX implementation and the CVXPY implementation was actually the scaling! I just tried by scaling everything done by 1e11 and it is now producing some result (with Mosek 11.2.2)

Thanks a lot for your help.

5

Thank you for your answers!

The scaling was indeed the issue. Scaling down and using Mosek 11.2.2 made it work

Thanks a lot for your help.

6

Thank your for your answer,

Scaling down did allow me to obtain a bounded result, although both implementation do not fully agree. Good to know it is to be expected!