Different solution using different solvers

hello,
I am trying to solve the SOCP problem using CVX.
I am getting infeasible solution while solving the problem with SDPT3. Following is the output.
Status: Infeasible
Optimal value (cvx_optval): +Inf

But, solving the same problem using Sedumi, I am getting feasible solution
Status: Solved
Optimal value (cvx_optval): +0.150178

Please let me know, why I am getting this difference. I am confused which result to trust.

Thank you.

Rahul

Perhaps the problem has poor numerical scaling. Are there numbers of large magnitude or small but non-zero magntude in the input data?

Can you directly verify that the solution from SeDuMi is feasible, at least within some tolerance?

Can you post a complete reproducible problem, with all input data?

All the variables are less than 1 (As I am solving the problem in pu)
I checked the SeDuMI solution, the solution seems feasible to me.
Also, I am experiencing for one condition both SeDuMi and SDPT3 works and for other none.
My problem matrix are big so unfortunately, I am unable to send you the code.

Regards
Rahul

If some numbers are not exactly zero, but are small in magnitude, such as 1e-6, that might cause numerical difficulties.

Try MOSEK and post the Mosek log and I am likely to be able to tell you if the problem is broken.

I have only two solver option either SuDuMi or SDPT3.
How can I connect MOSEK to CVX?

You need to install Mosek under MATLAB with a valid Mosel license. Then reinstall CVX, and Mosek should be recognized. I recommend you rename the mosek directory installed by CVX under the CVX directory - this will ensure the latest version of Mosek, which you install, is used by CVX, rather than an old version bundled in the CVX distribution.

Thank you for MOSEK suggestion.
I tried solving my problem with MOSEK, the problem is infeasible.
This is the result, I obtained from MOSEK.

Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 49
Cones : 1
Scalar variables : 304
Matrix variables : 0
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 : 3
Eliminator terminated.
Eliminator started.
Freed constraints in eliminator : 3
Eliminator terminated.
Eliminator - tries : 2 time : 0.00
Lin. dep. - tries : 1 time : 0.00
Lin. dep. - number : 0
Presolve terminated. Time: 0.02
Optimizer - threads : 4
Optimizer - solved problem : the primal
Optimizer - Constraints : 43
Optimizer - Cones : 2
Optimizer - Scalar variables : 173 conic : 41
Optimizer - Semi-definite variables: 0 scalarized : 0
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 : 946 after factor : 946
Factor - dense dim. : 0 flops : 3.44e+004
ITE PFEAS DFEAS GFEAS PRSTATUS POBJ DOBJ MU TIME
0 1.0e+000 6.6e+004 1.0e+000 0.00e+000 4.950000000e+004 4.950000000e+004 1.0e+000 0.03
1 5.0e-001 3.3e+004 3.5e-001 -1.00e+000 4.534838583e+004 4.949440557e+004 5.0e-001 0.06
2 1.5e-001 9.8e+003 5.7e-002 -1.00e+000 2.590700549e+004 4.950026027e+004 1.5e-001 0.06
3 8.4e-002 5.6e+003 2.5e-002 -9.99e-001 5.087157063e+003 4.949103909e+004 8.4e-002 0.06
4 2.2e-002 1.5e+003 3.3e-003 -9.97e-001 -1.293073763e+005 4.945655873e+004 2.2e-002 0.06
5 3.6e-003 2.3e+002 2.2e-004 -9.79e-001 -9.886990234e+005 4.917080361e+004 3.6e-003 0.08
6 3.9e-004 2.5e+001 1.1e-005 -8.27e-001 -4.697540269e+006 4.740080116e+004 3.9e-004 0.08
7 5.7e-006 3.8e-001 2.2e-007 -4.97e-002 -2.723911672e+006 4.507339733e+004 5.7e-006 0.08
8 2.5e-006 1.6e-001 1.8e-007 1.26e+000 -7.034301668e+005 4.502750169e+004 2.5e-006 0.08
9 1.2e-006 7.9e-002 1.4e-007 1.12e+000 -2.742235425e+005 4.501350446e+004 1.2e-006 0.08
10 2.8e-007 1.8e-002 7.5e-008 1.11e+000 -1.158147576e+004 4.500285050e+004 2.8e-007 0.09
11 1.3e-007 8.8e-003 4.2e-008 7.25e-001 3.184764236e+003 4.500176963e+004 1.3e-007 0.09
12 2.4e-008 1.6e-003 2.4e-009 -1.72e-001 -3.627929302e+005 4.500421625e+004 2.4e-008 0.09
13 2.0e-010 1.3e-005 2.9e-012 -7.85e-001 -2.322515701e+007 4.500223305e+004 2.0e-010 0.09
14 1.6e-012 6.5e-008 2.6e-012 -9.99e-001 -9.055357412e+000 -4.458621635e-009 2.9e-016 0.09
Interior-point optimizer terminated. Time: 0.09.

MOSEK DUAL INFEASIBILITY REPORT.

Problem status: The problem is dual infeasible
Optimizer terminated. Time: 0.14

Interior-point solution summary
Problem status : DUAL_INFEASIBLE
Solution status : DUAL_INFEASIBLE_CER
Primal. obj: -9.0553574022e+000 nrm: 2e+003 Viol. con: 3e-008 var: 0e+000 cones: 0e+000
Optimizer summary
Optimizer - time: 0.14
Interior-point - iterations : 14 time: 0.09
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: Infeasible
Optimal value (cvx_optval): +Inf

Elapsed time is 0.924060 seconds.

Are there any good reason your problem is not infeasible?

Technical details: Mosek detects the problem dual infeasible and that seems like a reliable conclusion.
Now most likely CVX dualized the problem before inputting it to Mosek. Hence, the dual problem is dual infeasible which means the primal is infeasible.

I am not sure about the feasibility of my problem.
I am curious, because I was getting feasible solution when I am using Sedumi but using SDPT3 and MOSEK the problem is infeasible.
Also, why the output value (x) is NaN when the problem is infeasible in cvx?
While using fmincon I am getting some value for x, even if the problem is infeasible.
Please clarify my doubt.
Thank you.
Regards
Rahul

If fmincon chooses to return a(n infeasible) value for x for an infeasible problem, that’s “Its own business”. CVX returns NaN for all CVX (optimization) variables for problems deemed to be infeasible

@Erling, the head honcho of Mosek, wrote that the determination of infeasibility seems like a reliable conclusion. Mosek is a most numerically robust and reliable solver than SeDuMi or SDPT3, so I would go with that conclusion.

In an earlier post in this thread, I asked whether you can directly verify that the solution from SeDuMi is feasible, at least within some tolerance. Have you attempted to do that/ If so can you show us your results one way or another?

On another note, you seem to be using some older version of Mosek like 7. Why not try the latest Mosek 9 also.

As I wrote before

I recommend you rename the mosek directory installed by CVX under the CVX directory - this will ensure the latest version of Mosek, which you install, is used by CVX, rather than an old version bundled in the CVX distribution.

I used the academic license for CVX and reinstall CVX. Here, I got MOSEK 8.0.0.60 version. I am looking into the feasibility issue for the problem.