Make use of SCS-3.2.8 new features

[kalmarek]

• complex PSD Cone (low level support for the complex psd cone #311 add MOI interface for complex PSD cone #315)
• Direct solver on the GPU (through cuDSS_jll)
  • requires compiling a new SCS_GPU-style library
• The loget cone
• the trace (or nuclear) norm cone
• ell1 norm cone (max of the sum of absolute column values)
• Ky Fan (or sum of the k largest eigenvalues) norm cone

[kalmarek]

I plan to add support for the new cuDSS library, as soon as #314 is resolved;

also, since we will need to release a new version with these changes, maybe it makes sense to switch to blastrampoline as well? (#296)

[odow]

I don't know enough about GPUs to fix #314. I'm just playing whackamole. It surprises me that there aren't any compat bounds in SCS_GPU_jll?

[odow]

requires recompiling SCS_jll with the new cones turned on

Why are they not on by default? Because it breaks the API like adding the complex PSD?

[araujoms]

You'll have to ask @dance858 or @bodono. It doesn't break the C API so that's definitely not the reason.

[dance858]

They’re not enabled by default in the C build because we haven’t officially announced SCS support for those cones yet. @Transurgeon is currently planning to work on integrating them into CVXPY. From what I understand, incorporating them isn’t straightforward. It requires solver-dependent canonicalization paths which CVXPY doesn’t currently implement (?).

If you decide to add support for them and want something to test with, there are a few examples in the spectral_examples folder of this repository: https://github.com/dance858/SpectralSCSExperiments

We also have a paper describing these examples in detail. It hasn’t been publicly released yet (it’s been stuck on a desk for a year), but I’d be happy to share a copy if you think it would be helpful.

[araujoms]

I can't speak for CVXPY, but supporting them in JuMP is quite easy. MathOptInterface already has the nuclear norm cone and the logdet cone, so we'd just need to write the bridge to SCS's format. It would be helpful if you could tell us what the format is, though. Are you assuming that the matrices are symmetric, and using the same vectorization as in the PSD cone?

A bit more work would be to support the Ky Fan cone, because first that would need to be written, but still is not a lot of work, as it's mostly copy-pasting.

[odow]

It doesn't break the C API so that's definitely not the reason.

Looks like it does to me:

https://github.com/cvxgrp/scs/blob/c8297172633bcb3a10d4781a19d4769ce5282d29/include/scs.h#L146-L163

This adds some new fields, and dsize, nucsize, ell1_size, and sl_size may not be initialised to 0 if we just pass in our existing

SCS.jl/src/c_wrapper.jl

Lines 49 to 65 in 45f1507

	mutable struct ScsCone{T} <: AbstractSCSType
	z::T
	l::T
	bu::Ptr{Cdouble}
	bl::Ptr{Cdouble}
	bsize::T
	q::Ptr{T}
	qsize::T
	s::Ptr{T}
	ssize::T
	cs::Ptr{T}
	cssize::T
	ep::T
	ed::T
	p::Ptr{Cdouble}
	psize::T
	end

It requires solver-dependent canonicalization paths which CVXPY doesn’t currently implement (?)

You may have already read it, but if not, see our paper on MathOptInterface https://arxiv.org/abs/2002.03447 😄

A bit more work would be to support the Ky Fan cone

Is it supported in any other solver? I guess we can first add it to SCS, and then add it to MOI if there is broader interest.

[araujoms]

It definitely breaks our interface, but not the C API. If you call SCS from C you pass it a struct, and only define the fields you're interested in. SCS handles internally the undefined fields correctly.

[odow]

It definitely breaks our interface, but not the C API

I guess we're arguing about a very subtle semantic difference. From my perspective, it breaks our interface, and we're calling the C API, so I regard it as a breaking change to the C API. The only non-breaking way to extend a public struct in C is to add new fields to the end, and only query their values if the caller explicitly opts in by setting some already existing field, or by calling a new function.

If there was ScsCone scs_new_cone(void); that we then got to set non-default fields, that would be non-breaking.

[odow]

I've opened a PR to Yggdrasil to recompile: JuliaPackaging/Yggdrasil#12314

Maybe it's time we changed to 300.200.900 version numbers?

[araujoms]

I'm talking about this code here I wrote: https://github.com/cvxgrp/scs/blob/master/test/problems/complex_PSD.h
I just create a ScsCone, and set the fields I need. It doesn't matter which other fields exist, it works all the same. Not that it matters, we can't do that from Julia anyway.

As for the version numbers, isn't that why we have build numbers? Wouldn't it be nicer to do 3.2.9+1?

[odow]

I just create a ScsCone, and set the fields I need

This requires the new header to know the correct size of ScsCone.

isn't that why we have build numbers? Wouldn't it be nicer to do 3.2.9+1?

No, because we already have 3.2.9, and if we tagged USE_SPECTRAL_CONES as 3.2.9+1 it would break our existing code. Hence, its a breaking change.

[araujoms]

The compat bound is strict, SCS_jll = "=3.2.9". Would that allow an update to 3.2.9+1?