cvx_begin quiet
variable V(N+1,N+1) hermitian
variable q
variable phi
expression sum_trace_BV
expression sum_trace_RV
sum_trace_BV = 0;
for k = 1:K
sum_trace_BV = sum_trace_BV + real(trace(B(:,:,sic_order(k))*V));
end
maximize q
subject to
%constrain14e
Gamma_k <= q;
%约束20 Tr(R_k_K*V) + |h_k_K|^2 <= ... <= Tr(R_k_1*V) + |h_k_1|^2 k in K
for k = 1 : K
for j = 1 : K - 1
real(trace(R(:,:,(k-1)*K+j)*V))+norm(h_k_j((k-1)*K+j))^2 >= ...
real(trace(R(:,:,(k-1)*K+j+1)*V))+norm(h_k_j((k-1)*K+j+1))^2;
end
end
%Constraint 21
sum_trace_BV + real(trace(V*I_hat))*sigmar2 <= Pr_max;
for k = 1 : K
2 * Yk(sic_order(k)) * phi ...
>= Yk(sic_order(k))^2 * (real(trace(D(:,:,sic_order(k))*V)) + nk2(sic_order(k))) + q;
phi^2 <= real(trace(R(:,:,(k-1)*K+k)*V)) + norm(h_k_j((k-1)*K+k))^2;
end
V == hermitian_semidefinite(N+1);
cvx_end
The above is my CVX code, in which some variables involved such as R, F, B, etc. are constants and have been calculated externally, but this problem cannot be solved using sdpt3 solver, and the state is ‘solved’ using sedumi solver but the numerical value is not correct. Please help to solve it
You have not provided a reproducible problem or shown solver output, so we can’t tell you what the difficulty is. Bad numerical scaling (very large or small magnitude input data,l is a common reason for numerical difficulties or failure of the solver. if you have Mosek available, try that, and pay attention to any warning messages it provides.
You have not shown us the sedumi output, nor told us why or in what way the solution is not correct.
If you remove quiet, you can see the solver output.
Thank you for your reply. In fact, I tried to use mosek solver, but when I used moske and mosek_2, different results appeared. Below I will show you the output of mosek and mosek_2 and the values of some variables, in addition, I will add the quadratic transformation method used at specific places in the code. If you can help me solve the problem, I would really appreciate it
When I substituted the variable V solved by mosek_2 into my objective function expression, some unexpected results appeared, such as the SINR calculated to be negative.
Your Mosek_2 is actually Mosek 10.2.7, which is much more recent than Mosek 9.1.9 which was used in the first solve. Perhaps that newer version of Mosek is more numerically robust and able to overcome difficulties that the older version couldn’t.
In any event, I have no idea what you did to arrive at your negative SINR. The objective in the program you show is the variable q. Therefore, there is no computing required to determine the objective function. So apparently you did something else, to evaluate something which I don’t know what it is. As to why this SINR, whatever it is and however you calculated it, is negative, I have no idea. Perhaps there is either a tolerance issue (constraints can be violated by up to a feasibility tolerance, and are still considered to be satisfied by the solver and CVX), or your model or calculations are deficient for the purpose for which you are trying to use them. This forum has readers knowledgeable in how CVX works, and how the solvers it calls work (most especially Mosek), but they are not subject matter experts in your application area or research problem; therefore the responsibility for producing an optimization model suited for your purpose is up to you.
You can use the optimal value of V as you wish. The same with variables q and phi. In order to be guaranteed to be correct, all expressions have to be recomputed after cvx_end, starting from the optimal variable values.
I see thatsigmar2, having value 1e-10 is used in your program. It might be indicative of bad numerical scaling, as i suggested might be a possibility in my first post. That might be contributing to numerical difficulties, either in the solver solving the problem, or perhaps in your post-processing of the solution. You should try to get all non-zero input data to be within a small number of orders of magnitude of 1. Change units of variables and data if necessary to do this. The value of phi is also rather small, although perhaps it is just the case that its optimal value is actually zero.
