[WIP] QuadraticModels extension

[klamike]

Blocked by #30

To allow us to solve models coming from ExaModels, ADNLPModels, etc.

• Add support for taking GPU problems directly

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/problems/milp.jl	66.66%	1 Missing ⚠️
src/utils/mat_coo.jl	66.66%	1 Missing ⚠️

Files with missing lines	Coverage Δ
ext/CoolPDLPQuadraticModelsExt.jl	100.00% <100.00%> (ø)
src/problems/milp.jl	81.25% <66.66%> (-1.51%)	⬇️
src/utils/mat_coo.jl	64.51% <66.66%> (+0.23%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[klamike]

@gdalle Added an interesting application here as a test case. We form a taylor approximation of an ExaModels ACOPF (here, at the locally optimal solution found by Ipopt) then solve it with CoolPDLP. It's pretty heavy so might be better to simplify for the sake of CI time before merging though.

[gdalle]

The extension is a good idea but I don't see why the power model application belongs in our test suite. It's very specific and adds several dependencies that would otherwise not be needed. Can we limit ourselves to checking the correctness of the conversion, since that is the only thing added to the source code?

[klamike]

Same page! Just wanted to show you why it’s cooler than it seems :)

[gdalle]

Why would ignore_islp suffice to get a linearization though? Don't we need the gradient of the nonlinear part of the objective / constraints too?

[klamike]

We call this very nice method of QuadraticModels.jl: https://github.com/JuliaSmoothOptimizers/QuadraticModels.jl/blob/2780658f64d48ab7563a843ed0ee03f54858e358/src/qpmodel.jl#L229-L274 (in the tests, not the source)

[klamike]

The source code doesn't do any linearization, it should be the same exact mathematical model, just different wrapper types. I'm not opposed to removing the ignore_islp to just always error if there are any quadratic terms. Then with #28 we can remove the check entirely.

[gdalle]

Accessing private fields is generally considered an antipattern in Julia. Besides, the try/catch might lead to type instability. I think we better handle it via dispatch (but I'm not sure how).
As a first step, we might allow At to have a different type than A. In the setting where the user provides two linear operators (lazy matrix-vector products), they have no reason to share the same type anyway.