When I use the SDP3 solver to solve the SDP problem. The command window shows as follows:
SDPT3: Infeasible path-following algorithms.
What does the above sentence mean?
The status is “Unbound” and cvx_optval is “+Inf” .
However, I have checked the formulated problem. The cvx_optval cannot be “+Inf” as I analysed.
I have searched the corresponding problem, i.e., the problem of “Unbound”.
You have replied as follows:
The solver ran into numerical difficulty. Perhaps a different solver will do better. It may be that the scaling of your problem is bad, and the solver would work better if you changed the units in your problem to make the coefficients closer to 1 in magnitude (i.e., no very large or small exponents).
Actually, I have scaled of my problem. But I think that the scaling method I used is applicable, although the values of the introduced scaling variables may be samll.
Can I try to use the other solver? Which solver is better?
number of iterations = 31
residual of dual infeasibility
certificate X = 8.45e-14
reldist to infeas. <= 6.08e-18
Total CPU time (secs) = 0.46
CPU time per iteration = 0.01
termination code = 2
DIMACS: 1.2e-04 0.0e+00 1.1e-01 0.0e+00 -1.0e+00 3.7e+00
Status: Unbounded
Optimal value (cvx_optval): +Inf
If you have Mosek available as solver, use that, becasue it it the most (numer8ically) robust solver and provides the best warning and diagnostic information. Otherwise try SeDuMi. I predict Mosek will give a warning about large magnitude numbers, which are likely making the solution of your problem unrelaible.
If after fixing the problem scaling, the problem is still reported to be unbounded, please read https://yalmip.github.io/debuggingunbounded/ , which, other than some syntax differences, applies to CVX as well as to YALMIP.
Regarding “The command window shows as follows SDPT3: Infeasible path-following algorithms.” Don’t worry about it. That is just a generic description of SDPT3’s algorithm. It says nothing about what happened when SDPT3 was invoked to solve the problem CVX provided it.
Sir!
I think the problem is not resulted by the introduced scaling variables. Although the scaling variables is small, I have adopted the similar scaling method in my previous cvx code which is about the SOCP problem and it worked.
The difference is that this problem is about the SDP problem.
Well, maybe you got away with bad scaling in your SOCP, and didn’t get away with bad scaling in your SDP problem. SDP can be (numerically) trickier and more difficult to solve than SDP, so it could be more sensitive to being adversely affected by bad scaling.
When you see numbers like 5e16 in the solver output, that generally a sign of bad scaling, and could result in the solver getting in great difficulty and being unreliable.
As i wrote in my previous reply, try Mosek if you can, and pay attention to its warning messages.
All points to the conclusion that your problem actually is unbounded. In fact note that the older Mosek 8 determined dual infeasibility already in presolve, which is pretty strong evidence. It can also indicate that you made some simple mistake in the code, like optimizing a wrong variable etc.
@Michal_Adamaszek Well I’ll be (to use a Southern U.S. expression). Mosek did not issue a warning about large coefficients. Is it “normal” that SDPT3 (i know it is not your product) could have such large numbers as 5e16 in its iteration log output for a problem which is “only” unbounded", but is well-scaled?
@Michal_Adamaszek How were you able to determine what Mosek 8 would have done on this problem? You don’t have a repoodicuble problem to run, as far as I know.
@Erling So you can determine from the Mosek 9.1.9 log what Mosek 8 would have done differently? That’s what I was wondering about.
I am actually set up to easily switch between Mosek 9.2.x and Mosek 8.1.0.80 because I know there were major changes from Mosek 8.1 to Mosek 9.0 and there is a chance Mosek 8.1 might work better on some problems than Mosek 9.2.
Sir!
I will try to use the YALMIP to solve the problem.
Does the YALMIP has the similar command , i.e., “expression holder” as shown in the cvx toolbox!
Sir!
I will try to use the YALMIP to solve the problem.
Does the YALMIP has the similar command , i.e., “expression holder” as shown in the cvx toolbox!
YALMIP has irs own different way of dealing with the situation covered by CVX’s expression holders. Both CVX and YALMIP need workarounds to deal with a limitation caused by how MATLAB works under the hood, forcing users into less natural commands than seem ideally necessary.
If you have detailed YALMIP questions, I suggest you ask at the YALMIP forum https://groups.google.com/forum/?fromgroups#!forum/yalmip .AFTER reading the YALMIP wiki online entries at https://yalmip.github.io/tutorials/ . The YALMIP forum has the advantage over the CVX forum that the developer (Johan Lofberg) answers the questions, unlike the CVX forum, where users such as myself, and Mosek developers such as @Michal_Adamaszek and @Erling are doing most of the answering, and the developer only rarely answers questions on the board nowadays (YALMIP is also in a much more active state development than CVX)…