-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inaccurate solution for simple QP problem #36
Comments
Update: I just tried the latest version (v0.7.1) in Python and I got a similar answer [0.9999668636034095, 3.313639612649994e-05]
|
I think that the issue is only in the interpretation of the error tolerances. The primal and dual feasibility tolerances are checked against the residuals of the KKT conditions. In this case when I manually compute the dual residual The primal objective function at the solution produced by the solver is also really close, i.e. The error you are computing is the distance between the (approximate) optimizer produced by the solver and the true optimizer. This is not one of the stopping criteria, and indeed really can't be because there is no obvious way to compute this distance when the true optimizer is not known. Normally you would not expect to get a substantial inaccuracy in the optimizer like that anyway. The reason it happens in this case is because the unconstrained minimizer for the problem happens to be at the boundary of the feasible set. The solution is therefore quite insensitive to small variations around that point, and the solver has produced a solution that is at a nearby point on the boundary with very similar objective value. Part of the issue is perhaps also one of method. A simplex based solver would be more likely to produce a very high accuracy optimizer for this problem because the true solution is right on a vertex. A possible fix for this would be for us to implement a "polishing" post-processing step as we did in OSQP. That would only be directly applicable to LP / QP problems, although I am aware that there is at least some work out there on similar polishing methods for problems with other constraint types. |
Thank you so much for the quick response, @goulart-paul ! |
Feel free to close this issue. Or you can leave it open if you think that such a "polishing" post-processing step could be implemented also for Clarabel. |
Hi @goulart-paul, I was noticing some strange results with Clarabel (using v0.7.0) and I was able to reproduce it in the form of a simple QP with 2 variables, 1 equality constraint and 2 inequality constraints. The code in C++ looks like this:
The correct solution should be (1, 0), but the solution that is provided has an error of 1e-4 even though Clarabel reports primal and dual feasibility of 1e-12.
Obtained solution from Clarabel = 0.999967 3.31364e-05
I attached the complete output as a txt file. Do you have any idea what is going wrong for this problem?
simple_qp_output.txt
The text was updated successfully, but these errors were encountered: