If you remove cvx_precision('best'); then it solves very nicely. After Easter we can try to investigate in more detail what is going on with the precision parameters that stops it working with your settings.
Using cvx_precision('best') makes CVX set many Mosek termination tolerances to 0.0, which leads to unexpected behaviour. Whether it is a Mosek issue or a CVX issue is yet to be determined :). You can circumvent it by setting those parameters manually, for example
As the one of the main author of the interior-point optimizer in Mosek I strongly recommend against using
cvx_precision(‘best’);
with Mosek. If I had been @mcg I would never ever have added this option to Cvx. Never.
In fact I strongly recommend using the default settings because that is for the vast majority of problems is the maximum precision that can be obtained.
If you should change options you should change the original options of the optimizer and think very careful what you should change.
I think the logic in cvx_precision(‘best’); is simple and makes sense.
It says, I will let the solver work until it decides there is nothing more to do.
I guess MOSEK doesn’t support this mode of operation for some reason.
@Erling, I’d be happy of you shed some information about why.
Another interesting observation I had is that SDPT3 is faster than MOSEK on some cases. I was surprised by that. Are you aware of such cases?
is a bad idea because due the usage of finite precision floating point numbers implies you rarely can get a higher accuracy than the default setting specified in Mosek. So you are just wasting computation time trying. Normally that is considered a bad for the environment due the CO2 emission.
For instance if you have huge matrix variables then SDPT3 at least in theory has an advantage because they use the HKM search direction where we use NT direction. But there can be other reasons as well. On average (whatever that means) we should be faster.
Maybe you are right that SDPT3 is faster on your instances, but you should examine the logs carefully to see that both solvers reach the optimal solution and don’t terminate prematurely (or stall in the end resulting in many iterations with limited progress).
I agree with Erling’s criticism, in hindsight. The cvx_precision('best') setting works really well with SeDuMi, which was the first solver we built support for. The reason for this is that the very specific way SeDuMi handled its stopping criteria meant that I could reliably just let it run until it could make no progress. But most solvers really don’t work so well that way.
So yes, cvx_precision('best') is not recommended, and it’s likely not going to ever be fixed.