Closed jorgenin closed 1 month ago
Thanks @jorgenin for reporting the issue.
This is a defect of Drake's IpoptSolver. For a matrix of linear constraints, we treated all entries in the coefficient matrix as non-zero values. I will work on a fix PR to handle the sparsity in the coefficient matrix.
Related to #18292.
What happened?
I was playing around with the mathematical program in both Casadi and Drake and I found some weird issues how linear constraints are evaluated.
In particular it seems like putting a matrix into a linear constraint many non-zeros to appear in the Jacobian. This greatly slows down the ipopt solver.
As a motivating example I've added a quick test file that compares two approaches in drake and then also an implementation in casadi. drake_ipopt_issue.py.zip
The first version added the program constraints as such:
Looking at the solver output this generated:
When we change those lines to use a loop instead as such:
We get instead:
Casadi has the same number:
Looking at solve times we see that the large number of nonzero greatly affect the solve time (though casadi is faster than either approach still by large margin)
Solve time First Program: 0.7652149200439453 Solve time Fixed Version: 0.11430883407592773 Casadi Solve Time: 0.012894868850708008
I saw a similar (though slightly different) issue mentioned in #18292. I took the liberty in using their values for IPOPT settings.
Version
No response
What operating system are you using?
macOS 14 (Sonoma)
What installation option are you using?
pip install drake
Relevant log output
No response