I want to solve the following problem with cvx.
Could someone please help me to find the reason for not satisfying the constraints?
my code is:
the input parameters are like this:
A_uu = zeros(4,4);
A_uu(2,1)=1;
A_uu(4,3)=1;
G = [1 0 1 0];
P_hovering = 0;
P_AA_max = 0.1;
P_U_max_FSO = 3;
sigma2_A = 9.97e-12;
lamda2_AA = [0,4.57e-12,1.42e-12,0,0,0,0,2.32e-10,8.63e-10,2.83e-13];
r_device_min = 1e3;
B_A_U= 5e6;
sigma2_S_FSO= 3.104e-11;
eta =1 ;
G_D =1 ;
H_AS_FSO = [0.02,0,0.034,0];
B_S_FSO= 3e+10;
and the cvx optimization is:
cvx_begin
variable P_AA_C(4,4) nonnegative
variable P_AS_FSO_C(1,4) nonnegative
minimize sum(sum(A_uu .* P_AA_C,2)) + sum(P_AS_FSO_C .* G) + P_hovering
subject to
0 <= P_AA_C <= P_AA_max;
0 <= P_AS_FSO_C <= P_U_max_FSO;
-(log((sigma2_A/10^(-10) + P_AA_C(2,1)/3 * lamda2_AA(2)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2) <= 0;
-(log((sigma2_A/10^(-8) + P_AA_C(2,1)/3 * lamda2_AA(9)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2) <=0;
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(3)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2) <= 0;
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2) <= 0;
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(10)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2) <= 0;
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,1)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,1)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,1)))./B_S_FSO) + log(sigma2_S_FSO)/log(2) <= 0;
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,3)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,3)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,3)))./B_S_FSO) + log(sigma2_S_FSO)/log(2) <= 0;
cvx_solver Mosek %Gurobi %SeDuMi %GLPK SDPT3 %Mosek % Choose the underlying solver
cvx_end
Optimal = cvx_optval;
I just ran it, and Mosek 9.3.20 found a declared optimal solution.
Calling Mosek 9.3.15: 81 variables, 20 equality constraints
For improved efficiency, Mosek is solving the dual problem.
------------------------------------------------------------
MOSEK Version 9.3.20 (Build date: 2022-4-27 08:24:47)
Copyright (c) MOSEK ApS, Denmark. WWW: mosek.com
Platform: Windows/64-X86
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col '' (62) of matrix 'A'.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col '' (68) of matrix 'A'.
MOSEK warning 710: #1 (nearly) zero elements are specified in sparse col '' (74) of matrix 'A'.
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 20
Cones : 7
Scalar variables : 81
Matrix variables : 0
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.02
Lin. dep. - number : 0
Presolve terminated. Time: 0.05
Problem
Name :
Objective sense : min
Type : CONIC (conic optimization problem)
Constraints : 20
Cones : 7
Scalar variables : 81
Matrix variables : 0
Integer variables : 0
Optimizer - threads : 8
Optimizer - solved problem : the primal
Optimizer - Constraints : 4
Optimizer - Cones : 7
Optimizer - Scalar variables : 29 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 : 4 after factor : 4
Factor - dense dim. : 0 flops : 4.40e+01
ITE PFEAS DFEAS GFEAS PRSTATUS POBJ DOBJ MU TIME
0 1.0e+00 2.5e+01 1.5e+02 0.00e+00 1.467263625e+02 0.000000000e+00 1.0e+00 0.08
1 1.2e-01 2.8e+00 3.8e+01 -8.52e-01 8.858926030e+01 -1.036400711e+00 1.2e-01 0.25
2 1.7e-02 4.1e-01 3.0e+00 1.28e-01 1.563559040e+01 -2.296897666e+00 1.7e-02 0.25
3 2.0e-03 5.0e-02 1.2e-01 8.65e-01 2.027741188e+00 -2.888973782e-01 2.0e-03 0.27
4 2.4e-04 6.0e-03 4.6e-03 1.17e+00 1.692744086e-01 -8.813431240e-02 2.4e-04 0.27
5 2.3e-05 5.7e-04 1.5e-04 9.73e-01 1.680087723e-02 -8.377804388e-03 2.3e-05 0.28
6 2.2e-06 5.5e-05 4.1e-06 1.02e+00 1.741081558e-03 -6.588689066e-04 2.2e-06 0.28
7 1.0e-07 2.5e-06 4.0e-08 9.97e-01 7.647002643e-05 -3.193506437e-05 1.0e-07 0.30
8 1.1e-08 2.7e-07 1.4e-09 9.83e-01 8.033451274e-06 -3.648781820e-06 1.1e-08 0.30
9 3.2e-10 7.8e-09 7.1e-12 9.98e-01 2.464247680e-07 -9.893279039e-08 3.2e-10 0.31
10 3.6e-11 8.8e-10 2.3e-13 1.06e+00 2.948364646e-08 -7.917313862e-09 3.6e-11 0.31
11 3.8e-12 9.3e-11 6.5e-15 1.10e+00 3.218524048e-09 -5.252038049e-10 3.8e-12 0.33
Optimizer terminated. Time: 0.47
Interior-point solution summary
Problem status : PRIMAL_AND_DUAL_FEASIBLE
Solution status : OPTIMAL
Primal. obj: 3.2185240483e-09 nrm: 7e+00 Viol. con: 3e-11 var: 0e+00 cones: 0e+00
Dual. obj: -5.2520380494e-10 nrm: 3e+01 Viol. con: 0e+00 var: 6e-10 cones: 0e+00
Optimizer summary
Optimizer - time: 0.47
Interior-point - iterations : 11 time: 0.33
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: Solved
Optimal value (cvx_optval): +5.25204e-10
>> disp(P_AA_C)
0.100000000000000 0.100000000000000 0.100000000000000 0.100000000000000
0.000000000182957 0.100000000000000 0.100000000000000 0.100000000000000
0.100000000000000 0.100000000000000 0.100000000000000 0.100000000000000
0.100000000000000 0.100000000000000 0.000000000182957 0.100000000000000
>> disp(P_AS_FSO_C)
0.000000000079502 3.000000000000000 0.000000000079788 3.000000000000000
Nevertheless, Mosek issued warnings about nearly zero elements in input data. You input numbers such as e-13,e-12, etc. are not good things to have in your program. You should re-scale, by changing the units used so that all non-zero input data is within a small number of orders of magnitude of one. Then try-rerunning.
Given your getting a report of infeasible, perhaps you are not using the most recent Mosek version. if so, you should update Mosek to the latest (stable) version. Perhaps it will do better.
Mosek 9.1.9 is included with CVX 2.2. Even if you install a later version of Moek, CVX will by default still use Mosek 9.1.9. To avoid that, you could either rename the cvx/mosek directory to something else, or just delete it. Then re-run cvx_setup, and whatever version of Mosek is in your MATLABpath will be the only Mosek version under CVX. Alternatively, issue the command cvx_solver,and then you will see all versions of Mosek in the MATLAB path, and you can use the long name, such as cvx_solver Mosek_2, or whichever one is correct, to invoke that. And you can use save_prefs to make that the default solver for future sessions.
Dear Mark:
Thank you for your reply.
Yes, the problem is solved, but the answers do not satisfy the constraints.
I also think it’s because of the nearly zero elements that I use. What should I do to resolve this issue?
4 of the constraints have a violation of 2e-4. My guess is that is attributable to the bad scaling.
>> -(log((sigma2_A/10^(-10) + P_AA_C(2,1)/3 * lamda2_AA(2)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log((sigma2_A/10^(-8) + P_AA_C(2,1)/3 * lamda2_AA(9)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(3)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(10)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,1)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,1)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,1)))./B_S_FSO) + log(sigma2_S_FSO)/log(2)
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,3)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,3)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,3)))./B_S_FSO) + log(sigma2_S_FSO)/log(2)
ans =
-6.643656189775133
ans =
1.999923841609075e-04
ans =
1.999999874655600e-04
ans =
1.999979526345896e-04
ans =
1.999999974984235e-04
ans =
-0.001477141494476
ans =
-0.004280405057742
You need to change the units you use in order to improve the scaling. For instance (this is just a made up example, not necessarily applicable to your problem0, use Hertz instead of Gigahertz, which will make the corresponding numbers 1e9 times larger.
Thank you
I changed the code to below. All CVX input values are between 10^3 and 10^-3, but again the logarithmic constraint is not satisfied!!
But the range of variables (P_AA_C) also changed and has become about 10^-3 and 10^-2.
sigma2_A = sigma2_A/10^(-10);
lamda2_AA = lamda2_AA./10^(-10);
MM = log(sigma2_A*10^(-10))/log(2);
cvx_begin
variable P_AA_C(4,4) nonnegative
variable P_AS_FSO_C(1,4) nonnegative
minimize sum(sum(A_uu .* P_AA_C,2)) + sum(P_AS_FSO_C .* G) + P_hovering
subject to
0 <= P_AA_C <= P_AA_max;
0 <= P_AS_FSO_C <= P_U_max_FSO;
(-(log(sigma2_A + P_AA_C(2,1)/3 * lamda2_AA(2)))+23.0259)/log(2) + r_device_min/B_A_U + MM + 10^(-10)<= 0;
(-(log(sigma2_A + P_AA_C(2,1)/3 * lamda2_AA(9)))+23.0259)/log(2) + r_device_min/B_A_U + MM + 10^(-10)<=0;
(-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(3)))+23.0259)/log(2) + r_device_min/B_A_U + MM + 10^(-10)<= 0;
(-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(8)))+23.0259)/log(2) + r_device_min/B_A_U + MM + 10^(-10)<= 0;
(-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(10)))+23.0259)/log(2) + r_device_min/B_A_U + MM + 10^(-10)<= 0;
cvx_solver Mosek %Gurobi %SeDuMi %GLPK SDPT3 %Mosek % Choose the underlying solver
cvx_end
Optimal = cvx_optval;
I ran your modified version, and got a maximum constraint violation of 3e-6, which is not too bad, although not great. Solvers are allowed to produce solutions which violate constraints within a feasibility tolerance. Mosek reported primal constraint violation of 7e-10; so the larger constraint violation in your original formulation presumably arises due to the transformation between your problem as entered in CVX, and the problem provided by CVX to Mosek to solve (which among other things, is the dual)…
>> -(log((sigma2_A/10^(-10) + P_AA_C(2,1)/3 * lamda2_AA(2)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log((sigma2_A/10^(-8) + P_AA_C(2,1)/3 * lamda2_AA(9)/10^(-8))*10^(-8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(3)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(8)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_A + P_AA_C(4,3)/3 * lamda2_AA(10)))/log(2) + r_device_min/B_A_U + log(sigma2_A)/log(2)
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,1)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,1)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,1)))./B_S_FSO) + log(sigma2_S_FSO)/log(2)
-(log(sigma2_S_FSO + ((P_AS_FSO_C(1,3)) .* (eta ^2) .* (G_D ^2) .* (abs(H_AS_FSO(1,3)) .^ 2))))/log(2) + ((r_device_min .* (5.* G(1,3)))./B_S_FSO) + log(sigma2_S_FSO)/log(2)
ans =
-6.643656217876146
ans =
-3.305704093548023e-04
ans =
-7.862150295538939e-04
ans =
-0.152598227551828
ans =
3.397713431496641e-06
ans =
-5.653267928680872
ans =
-7.190464614674529
And all bound constraints were strictly satisfied.