Could anyone help me with this output? I should mention that the main algorithm is an alternative optimization algorithm to optimize each variable one at a time by fixing the other variables. So, at the first iteration, it is solved but as it moves forward suddenly this error pops up. Any help is greatly appreciated.

MOSEK warning 960: E[53,0] = -4.1e+10 is large in absolute size.
MOSEK warning 960: E[53,1] = -9.4e+10 is large in absolute size.
MOSEK warning 960: E[53,2] = -1.9e+11 is large in absolute size.
MOSEK warning 960: E[53,3] = -6.3e+11 is large in absolute size.
MOSEK warning 960: E[53,4] = 1.7e+11 is large in absolute size.
MOSEK warning 960: E[53,5] = -1.3e+11 is large in absolute size.
MOSEK warning 960: E[53,6] = 7.7e+10 is large in absolute size.
MOSEK warning 960: E[53,7] = 9.1e+10 is large in absolute size.
MOSEK warning 960: E[53,8] = -1.7e+11 is large in absolute size.
MOSEK warning 960: E[53,9] = -3.1e+11 is large in absolute size.
Warning number 960 is disabled.
Mosek error: MSK_RES_ERR_SYM_MAT_HUGE (A numerically huge value is specified for an element in A.)

Have you looked at the solution from each iteration of your one variable at a time algorithm? it apparently is diverging, creating huge values as input to the next iteration. I presume your algorithm is crude, with no safeguarding such as line search or trust region. There is a reason why high quality non-convex solvers are more than 10 lines of code long.

If you start from a different starting point,. you might (or might not) get lucky.

Thanks for your reply. Indeed, my problem is convex, and I would like to use the CVX! I encounter the following problem after getting NaN as a solution. I should state that I used cv_solver mosek for this problem and cvx_solver sdpt3 for the other ones. Could you please help me with this message? How could I avoid it? I would like to write an if condition statement to avoid such error if that is possible. I also checked other outputs, and their corresponding ranges are safe! Also, other problems can be solved efficiently but by adding this sub-problem everything falls apart. So, I was just wondering if by bypassing this NaN solution (defining if condition statement) and moving to the new iteration with new inputs, it might be solved. Thank you so much!

Maybe you can use NATLAB’s try/catch. I don’t know whether it will work in your case.

At this point, I have no idea what you’re doing or why.

Why are you using alternating coordinates instead of just submitting one problem for CVX to submit to the solver. Is the problem convex but not DCP-representable? None of the forum readers know what your problem is. And I don’t think any forum readers are going to write or debug an elaborate homebrew solver for you. if you write a higher level solver around CVX, you’re pretty much on your own.

Thanks for your reply. Since my problem is highly non-convex, I have to use alternating coordinate algorithm to solve convex problem at each step. Thank you for your suggestion, I will try that.

You wrote “Thanks for your reply. Indeed, my problem is convex” in reply to my statement “Maybe you should just use an existing non-convex solver, such as available under YALMIP.”. Now you say your problem is highly non-convex.

I wasn’t advocating you use a non-convex solver for each convex subproblem. I was suggesting you use a non-convex solver for the original non-convex problem, and not try to do a do-it-yourself alternating convex subproblem scheme. It seems pretty clear you don’t know what you’re doing in that regard, and this forum isn’t the right place to learn it.

Whether you are doing block coodinate descent or successive convex approximation or the combination of both, too many rounds of iterations with CVX could be unstable due to numerical issues, see the suggestion 6 in how-to-deal-with-an-issue-using-cvx. So you are responsible for the quality of your input data to every subproblem of every iteration.

When your data are too many, if you want to find out which data is bad, the only way might be using MOSEK diretly with MATLAB, not with CVX, so you can locate the bad data by reading the mosek warnings. But the bad news is that now you need to model your convex problem yourself, per https://docs.mosek.com/modeling-cookbook/index.html, without CVX’s help.

I guess you will never try a non-convex solver if you are just writing an academic paper, because the theoretical time complexity is huge, it is not nice looking to put that on your paper. And also, you might not need a global optimal solution in most cases, you need to obtain a low-complexity fine solution with your home-made method, which might be the highlight of your paper.

Thank you for your reply. I found that why that error pops up! Basically, I used a huge value for the penalty factor for that specific sub-problem as I apply a successive approximation convex technique which makes the problem not numerically intractable. However, by decreasing the penalty factor, I was able to handle it!

Yes, I do not want to use a non-convex solver as I have to come up with a convex problem for my academic paper.

By chance, do you have any relevant topic regarding beamforming with semidefinite relaxation technique?