Hi, I have a simple set of LMI’s for a feedback control problem that I have trouble solving due to numerics. I can’t seem to find a good way to scale the problem to make it easier for the solver. I am using Mosek. I have tried using slack variables which seemed help for some combinations of k1, k2, c1, c2, but I run into problems with the k1, k2, c1, and c2 below (mostly due to k2 and c2). Thank you for your help.
And try installing the most recent Mosek 10., and select that version with cvx_solver.
As for the scaling, can you divide all the input numbers by 10000, without getting into trouble with the 1 elements in` eye? Not obvious to me you can, but I leave any reformulation to your determination.
You haven’'t told us what alpha is. But it clashes with MATLAB’s alpha.
alpha is given in the first line of the code. It is set as 0.01. It is a scalar>0. It is a design parameter that sets the slowest decay rate of the closed loop system A+B*K for all combinations of A and B within the values k1-k2 and c1-c2
You haven’t shown us the CVX output.
Not sure what you mean, the output in the second code block is what cvx put in the Matlab command window. Is there a command I should run to display more information?
And try installing the most recent Mosek 10., and select that version with cvx_solver.
Sorry. I guess I had some scrolling issues. Your problem was determined to be (primal) infeasible, so read the corresponding ink from my previous post.
Id certain combinations of deleting two of the first 4 constraints are made, the problem becomes feasible. Presuming you want to keep tall those constraints:
You can add slack*eye(3) to the LHS of the last constraint. For values of slack up to about 1e7, that problem is reported as infeasible. Above that, it gets ill-posed as Mosek has numerical difficulties. Mosek 10.0.26 claims to have solved For slack = 1e7, but the solution is huge, and perhaps is just meaningless garbage. Perhaps Mosek 9.2.40 would report differently in this region. And it fails for slack = 1e-7. Mosek failed with primal ill-posed when II made slack a variable and minimize it, so that means the slack minimization problem is dual ill-posed. Mosek runs into never never land in the 1e7 region.
So basically, `Q doesn’t “want” to be PSD, even if given a huge eigenvalue increase. I’'m not a control theory person, so I’ll defer further diagnosis to someone else.
Edit: The problem is reported feasible for values of k2 up to just under 2e4, and infeasible for k2 >= 2e4.
Perhaps bad scaling is contributing to the difficulties. Is the problem inherently badly scaled, corresponding to vastly different time scales in the same problem? Maybe inherently ill-posed, at least for a double precision solver? Maybe this set of LMI’s isn’t so simple?
That is exactly what I was noticing as well. It does seem to be inherently badly scaled due to different time scales. The design goal is to create a controller that can handle a range of spring constants k1 to k2. The larger spring constant k2 corresponds to a much smaller time scale compared to the smaller constant k1. Also, a larger alpha corresponds to a more aggressive controller response (lower alpha should help with convergence but is not ideal for the actual problem). The problem might be solved if I could use a higher precision solver.
Using the ‘MSK_DPAR_INTPNT_CO_TOL_PFEAS’ option does seem to help at least for k2 = 2.7e5 (not 2.7e6) when using a slack of 1e-9. I can go up to alpha = 0.03 using this which is still lower than what I would like (ideally alpha > 0.1)
This is what I get for:
alpha = 0.03
k1 = 300;
k2 = 2.7e5;
c1 = 0.35;
c2 = 1000;
‘MSK_DPAR_INTPNT_CO_TOL_PFEAS’: 1e-12
https://www.tuhh.de/ti3/jansson/vsdp_cj.html (not really higher precision, but uses interval (and radial) arithmetic in INTLAB to do verified calculations - perhaps it will conclude the problem is in no man’s land where it can’t make a reliable feasibility determination one way or another. If you are going to get involved in these kinds of hairy situations, where you have to know for sure worst case error bounds, INTLAB (a MATLAB add-on) might be useful anyway.