We have no idea what your program is, other than that it involves a function utilizing the exponential cone.
If you have access to Mosek as solver, use it. Otherwise follow the directions at CVXQUAD: How to use CVXQUAD's Pade Approximant instead of CVX's unreliable Successive Approximation for GP mode, log, exp, entr, rel_entr, kl_div, log_det, det_rootn, exponential cone. CVXQUAD's Quantum (Matrix) Entropy & Matrix Log related functions .
It may also be the case that the numerical scaling in your problem is poor.
Please show all CVX and solver output.
Have you checked all the input data to make sure all the non-zero input data is within a small number of orders of magnitude of one? If that is not the case, change the units used in the problem, i.e., re-scale to try to get the non-zero input data to be within a small number of orders of magnitude of one.
Also, it’s possible the latest version of Mosek will do better.
Download the latest stable Mosek version, currently 10.1.13, from the Mosek werbsite. You can use that instead of Mosek 9.1.9, which is bundled with CVX 2.2…
To make sure you don’t wind up using Mosek 9.1.9 which is bundled with CVX 2.2:
First download latest Mosek from the Mosek werbsite and install it under MATLAB. Make sure
mosekdiag succeeds. Then reinstall CVX so it will find the new solver.
Either delete or rename the mosek directory under CVX (before reinstalling CVX)
cvx_solver shows all the versions of all the solvers available to CVX. Choose the Mosek 10.x version, which might be called something like Mosek_2, then use
cvx_solver Mosek_2 to get that version, and you can
In any event,
cvx_solver will show all the versions available to CVX.
Thank you! I’ll try. When I use SdDuMi, the result is inaccurate/solved. Can I trust this result? It didn’t make my optimization problems better, it made them worse. What causes this?
I wouldn’t trust that result without further investigation by you.
I don’t know what you mean by making the optimization problem worse. Worse than what? Do you already have a feasible solution, and the solution from CVX/SeDuMi is worse than that solution?
As I have said before, you need to check the scaling of the input data. Bad scaling may be causing or contributing to your problem. Also,l if you are using a solver other than Mosek, CVX is employing its Successive Approximation method, which is not very reliable or robust.
I used an alternate optimization algorithm. The above problem is the second step of my iteration, but its value is reduced compared to the first step.
Unsafeguarded (no line search or trust region)Successive Convex Approximation (SCA) or generally, alternating variables optimization are unreliable. It might not descend (for minimization problem), i.e., iterates could get worse. It might not converge to anything; and if it does converge, it might not be to a local optimum of the original problem, let alone a global optimum. The solution of successive iterations, and therefore subproblem inputs, can become wilder and wilder, until at some point the solver fails, or makes erroneous determination of infeasibility or unboundedness.
Don’t apply crude, unsafeguarded (no Trust Region or Line Search) Successive Convex Approximation (SCA) to a new problem … unless your name happens to be Stephen Boyd.
There’s a reason high quality non-convex nonlinear optimization solvers are more than 10 lines long.
May I ask what I should do now?
Perhaps consider using a non-convex nonlinear solver under YALMIP.
Thank you very much for your valuable advice. I’ll keep debugging.