-
Notifications
You must be signed in to change notification settings - Fork 24
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
textbook sos example that worked on v0.7.1 and fails on v0.9.0 #119
Comments
Hmm, I get different termination statuses on 0.7.1 depending on the chosen BLAS for the PSD constraints ( The big difference for me is that the objective value on 0.9 becomes NaN (for both BLAS), but on 0.7.1 the objective value is an actual number (for both BLAS). Do you by any chance use the objective in the loop? Also, just because I am curious, what is the NonnegativeConeT(0) doing here? |
This might actually be related to #120 . Using the infeasibility checks from the preprint (it seems as they were not implemented in the code) this problem seem to be consistently terminated as |
In oxfordcontrol/Clarabel.rs#119, they asked about why we declare a `NonnegativeConeT(0)`. I guess it's not wrong, but it's certainly inelegant. This PR avoids writing the zero-dimensional cones.
Thanks for pointing that out. It really shouldn't be there. I've opened RobotLocomotion/drake#21646 to update our parser. |
In oxfordcontrol/Clarabel.rs#119, they asked about why we declare a `NonnegativeConeT(0)`. I guess it's not wrong, but it's certainly inelegant. This PR avoids writing the zero-dimensional cones.
In oxfordcontrol/Clarabel.rs#119, they asked about why we declare a `NonnegativeConeT(0)`. I guess it's not wrong, but it's certainly inelegant. This PR avoids writing the zero-dimensional cones.
We recently upgraded Drake from v0.7.1 to v0.9.0, and I experienced a regression in one of my "simple" examples using sums-of-squares for Lyapunov analysis. Mosek, SCS, and Clarabel v0.7.1 solved it fine.
For context, you can find the original notebook here. Unfortunately, the failure happens inside some alternations... specifically in the
OptimizeLyapunov
method at the bottom of the notebook, and ifOptimizeMultipliers
uses Mosek, and onlyOptimizeLyapunov
uses Clarabel, then everything works.Nevertheless, here is the Clarabel-only reproduction of the final solve which now results in
Terminated with status = InsufficientProgress
.I know at least one relatively simple thing I can do to improve the numerics for this problem, but thought I should report the regression before I do.
The text was updated successfully, but these errors were encountered: