# Return infeasibility for a feasible model

Hello,

I am new to CVX, and currently trying a small example on cvx to see how it works, (the solver I use is Mosek).

The model I set is to minimize the sum of separable quadratic functions, and the constraints set values to all decision variables x(i) for i = 1,…, 22. Intuitively, this model must be feasible, and gives me the objective value by plugging in x values. However, cvx said this model is infeasible with obj = infinity. I do not understand why this happened. Can anyone help me with this?

I also tried the following things:

1. I changed the expression of the objective function to matrix-vector form, but it is still infeasible.
2. I changed the objective function to sum of separable linear function with the same constraints, it returns me the correct objective value.
3. I used the same separable quadratic objective function, but set constraints as for i = 1:num_arc x(i)==1 end., then it gives me the same objective value.

I got very confused of this. Thank you so much for any help and explanation.

n = 8;
num_arc = 22;
ai = [1, 6, 2, 10, 7, 8, 4, 10, 10, 10, 7, 5, 3, 10, 9, 10, 3, 4, 0, 6, 9, 10];
bivalue = [-8, -5, -3, -7, -1, -6, -7, -9, -6, -8, -5, -7, -10, -10, -9, -3, -8, -8, 0, 0, -4, -9]
ci = [5, 1, 8, 5, 1, 9, 9, 6, 4, 8, 1, 8, 4, 5, 8, 8, 5, 9, 10000, 7, 8, 10]

cvx_begin
variable x(num_arc)

``````obj = 0

for i = 1:num_arc
obj = obj + ai(i)*x(i)^2+bivalue(i)*x(i) + ci(i)
end

minimize(obj)
subject to

x(1) == 29292
x(2) == 57139
x(3) == 0
x(4) == 0
x(5) == 0
x(6) == 0
x(7) == 13569
x(8) == 0
x(9) == 0
x(10) == 29292
x(11) == 0
x(12) == 0
x(13) == 57139
x(14) == 0
x(15) == 0
x(16) == 0
x(17) == 0
x(18) == 0
x(19) == 70708
x(20) == 0
x(21) == 13569
x(22) == 0
``````

cvx_end

## log Calling Mosek 9.1.9: 66 variables, 22 equality constraints For improved efficiency, Mosek is solving the dual problem.

MOSEK Version 9.1.9 (Build date: 2019-11-21 11:32:15)
Platform: MACOSX/64-X86

Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 22
Cones : 22
Scalar variables : 66
Matrix variables : 0
Integer variables : 0

Optimizer started.
Presolve started.
Eliminator started.
Freed constraints in eliminator : 0
Eliminator terminated.
Eliminator - tries : 1 time : 0.00
Lin. dep. - tries : 0 time : 0.00
Lin. dep. - number : 0
Presolve terminated. Time: 0.03
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 22
Cones : 22
Scalar variables : 66
Matrix variables : 0
Integer variables : 0

Optimizer - solved problem : the primal
Optimizer - Constraints : 0
Optimizer - Cones : 7
Optimizer - Scalar variables : 21 conic : 21
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 : 0 after factor : 0
Factor - dense dim. : 0 flops : 0.00e+00
ITE PFEAS DFEAS GFEAS PRSTATUS POBJ DOBJ MU TIME
0 6.4e+00 1.4e+05 2.4e+01 0.00e+00 7.000000000e+00 -1.650000000e+01 1.0e+00 0.06
1 6.0e-09 6.4e-05 1.7e-06 -1.00e+00 -1.750000161e+01 -1.649999995e+01 4.0e-09 0.32
Optimizer terminated. Time: 0.43

Interior-point solution summary
Problem status : DUAL_INFEASIBLE
Solution status : DUAL_INFEASIBLE_CER
Primal. obj: -1.7500001606e+01 nrm: 7e-01 Viol. con: 0e+00 var: 0e+00 cones: 3e-09
Optimizer summary
Optimizer - time: 0.43
Interior-point - iterations : 1 time: 0.32
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

The input numbers are too big (much) for Mosek and SeDuMi to handle correctly, although SDPT3 reports an optimal solution with objective value 4.1e10.

The moral of the story: if you want to screw up double precision solvers, it is possible to do so. Indeed if you look at other CVX forum threads, you can see many posters are encouraged to improve the scaling of their input data, so that non-zero elements are within a small number of orders of magnitude of 1.