Set request: ScaledPSDCone

[blegat]

The scaled PSD cone was removed in #176 arguing that it is not useful when modeling.
However, some solvers such as SCS and Mosek uses it internally and need to transform the unscaled PSD coefficients to the PSD coefficients and also transforming constraintprimal and constraintdual values.
If we add the scaled PSD cone back, these transformations could be factored out of the solver wrappers into a bridge in MOI.
This might seem inefficient to have a bridge for such simple transformation but in fact if implemented as a light bridge (see #523), it shouldn't have more overhead that the transformation currently carried out in the solver wrappers. At least there would be only one place to check for performance.
What do you think ? Should we bring it back ?

• Bring it back ! 👍
• Do not bring it back ! 👎

[chriscoey]

Yes please!

[chriscoey]

Looks like we can move ahead with this?

[mlubin]

Do we really need three versions of the PSD cone? It's a lot of complexity to manage within MOI.

Light bridges could shift the balance, but they don't exist yet.

[chriscoey]

What is the timeline for the lighter bridges?

[mlubin]

After JuMP 0.19

[chriscoey]

Ok. This year?

[mlubin]

I don't know. I wouldn't recommend blocking your work on it.

[chriscoey]

The level of complexity that will need to be introduced on the solver side is unacceptable. I will wait. @blegat I'm prepared to help.

[odow]

I added the scaled PSD cone to SCS here: jump-dev/SCS.jl#219, along with a bridge from PositiveSemidefiniteConeTriangle.

A bigger issue than the scaling, which is easy to deal with, is the permutation of the cone. For now I think we're okay with non-standard bridges in the packages. We can revisit if lots of solvers end up using the same bridge and set.

[odow]

I'm going to close this issue. We don't need more complications at the MOI level.

We now have a good way for solvers to define their own bridges and expose them via the ListOfNonstandardBridges attribute.

There are also some differences with how the matrices are permuted (lower triangular or upper triangular), so the best course of action is to look at the SCS set and bridge and make the appropriate changes:

https://github.com/jump-dev/SCS.jl/blob/master/src/MOI_wrapper/scaled_psd_cone_bridge.jl

[blegat]

I'm reopening since not having this set starts to generate a lot of duplicate code across solvers:

• Mosek have to define exactly this set and the bridge from unscaled to scaled (that we can just copy-paste into MOI now) : Add support for Affine PSD constraints MosekTools.jl#128
• it would help for Hypatia (see @chriscoey comments in this thread above)
• it would help simplify SCS, COSMO and Clarabel which use the scaled cone internally
• it would help showing how easy it is to implement a conic solver including PSD with the tutorial https://github.com/blegat/SimpleConicADMM

I don't think we need to add the scaled psd square, scaled log-det etc... but the scaled psd triangle would definitely help