Replace OSQP with a hybrid HIGHS/OSQP solver interface #256
Conversation
|
Could you elaborate a little on the pros/cons of creating a separate HIGHS interface compared to a combined one? I don't find the fact that it is not suitable for very large problems concerning, since presumably MICOM users would know to use the OSQP interface? I don't think that the fact that this interface is slower than CPLEX & Gurobi is a problem. It would still be the only open source MILP solver that we have available in optlang. This would be extremely helpful for the memote webservice, for example, where we had to disable the MILPs. In summary, I'm not sure about splitting the interfaces but I definitely would like to have them ❤️. |
Sorry I wasn't clear here. I think there should be a HIGHS interface in optlang regardless. HIGHS is a great solver and it has another API (somewhat reminiscent of the GLPK API) that would fit well with optlang and be more efficient in terms of basis reuse and getting solution values. The QP solver in HIGHS is also pretty good for decent size problem (thousands of vars). OSQP is great for QPs but can't solve LPs well, which leads to issues in settings where you need to do both within the same interface. That applies to MICOM but also other examples (MOMA in COBRAPY is another example). So this combines OSQP with HIGHS to cover all bases. Maybe it should even replace the OSQP interface since it would still retain all functionality but would provide an excellent LP/MILP fallback in the same interface as well... 🤔 If that is not a good fit I cold also just add it to MICOM though.
I mean GLPK has a MILP solver, it just struggles with certain types of problems. Which specific MILPs are you running in MEMOTE? I could benchmark some with my COBRAPY branch that has the interface enabled to see if it would be helpful there.
Yeah they will definitely both be in optlang eventually. I do want to get on the HIGHS interface as well but it might take a bit longer since it would have to be coded from the ground up and there are more methods to overwrite. |
|
Okay, from my understanding of your description, it sounds like it might be best to have one combined HIGHS-OSQP interface and a separate HIGHS interface. With regard to MEMOTE, there are a couple of MILP in the |
|
Okay perfect, I'll change it into that then. |
|
The only MIPs I found in memote for now where |
|
Something like Recon3D is probably the biggest that we have. Super cool to hear about the comparable speed ✌🏼 |
Same for Recon3, just takes around 9s for either, but again there are no violations, so I could imagine that it is different for models with actual inconsistencies. |
cdiener
changed the title
|
Oh yeah, if there are none, then it is a very fast MILP. |
|
I would probably be inclined to pull this by November 14 (2 month wait) if I get no reviews because it is high priority for us. It is tested pretty extensively now and avoids returning astonishingly wrong/non-optimal LP solutions in the OSQP interface. |
|
By pull, you mean merge? I'm sorry, I didn't realize you were waiting on me. I thought you were still making modifications. |
|
Yep I meant merge. It has been done for a while. I fixed some edge cases that came up testing some larger models, but it has been done for a while . |
Co-authored-by: Moritz E. Beber <[email protected]>
|
Thank you! |
This is a proposal for a new interface that leverages the matrix interface to combine HIGHS and OSQP in a general purpose large problem solver. This was designed with MICOM in mind, so I am not completely sure whether it's in scope here (see pro-con below). It passes all the generic tests in optlang and also the full COBRAPY suite.
Pro
Cons
So let me know what you think.
COBRAPY tests and benchmarks