eigen_solvers header

[aamijar]

Cugraph can't include the current .cuh implementation, so we need to add a header .hpp.
@jnke2016

[cjnolet]

If cuGraph is using spectral clustering, I'd like to see us move towards a unified spectral clustering API instead of exposing this solvers API just for that library. Solvers belong in RAFT. end-to-end algorithms (like spectral clustering and spectral embedding) belong in cuVS.

[aamijar]

Agreed. This PR is just to unblock rapidsai/raft#2813

[cjnolet]

Yes, but we aren't exposing APIs in cuVS just to unblock others. We need to do it properly. APIs become much more expensive in cuVS because they are strictly compiled into cuVS (unlike raft, where they are header only).

[jnke2016]

@cjnolet do you think we should discuss it with the cuGraph team for other alternatives? @ChuckHastings

[cjnolet]

@jnke2016 @aamijar cuvs is not going to expose an eigen solver. That's what raft is for. If cugraph needs an eigen solver it should use raft for that. If it needs spectral clustering, it should use cuVS.

If it's because we lack a spectral clustering api in cuVS which is flexible enough, we need to fix that in cuVS. No band aids.

[jnke2016]

@cjnolet got it. I was asking if we should consider other alternatives like having cuGraph implementing its own spectral clustering with its primitives at some point.

[aamijar]

Thanks for the input.
In that case, I can just close this PR since there is no reason to have a wrapper for the solver that is already available in raft.

Yes, we are working on a proper spectral clustering API in cuvs. In the meantime are there any alternatives that cugraph can take so that we are able get this in rapidsai/raft#2813?

[cjnolet]

@aamijar getting these deprecated algos removed from raft is a p0 (more important than scaling the solver). I'd like for us to solve this problem correctly instead of just trying to get something done quickly.

Ideally if cugraph is using spectral clustering, we would be providing a first-class api that meets their needs. It sounds like they need spectral clustering and not just the solver.

Cc @dantegd

[aamijar]

Okay, I can reprioritize to work on the Spectral Clustering first, instead of the spectral scale up.

@jnke2016 Can you confirm that cugraph will be able to use a Spectral Clustering API that looks like this
https://github.com/rapidsai/cuvs/blob/branch-25.12/cpp/include/cuvs/preprocessing/spectral_embedding.hpp#L168-L171 except instead of providing the output embedding we will provide the output labels for each point.

Is there anything else we need to consider that cugraph is blocked on? I am seeing that this is likely the file that would need to be changed in cugraph.
https://github.com/rapidsai/cugraph/blob/58c09a6bf94c59c22d2c7a9693000b4edd089230/cpp/src/community/legacy/spectral_clustering.cu#L23-L24.
Can partition be replaced with Spectral Clustering API? And what would be the plan for modularity_maximization? Anything else that we should know?

[jnke2016]

Can you confirm that cugraph will be able to use a Spectral Clustering API that looks like this

@aamijar yes I can confirm. As you mentioned, the only thing cuGraph needs are the cluster/output labels

Is there anything else we need to consider that cugraph is blocked on? I am seeing that this is likely the file that would need to be changed in cugraph.

Correct, once cuVS has a version of spectral_embeddings that returns output labels for either partition or modularity_maximization , those two files will be deleted.

[aamijar]

Thank you @jnke2016 for confirming!

[cjnolet]

@aamijar @jnke2016 can we close this in favor of #1425 ?

[jnke2016]

@cjnolet Yes those solvers are not going to be exposed as you mentioned. And the new API is much simpler for cuGraph as it hides all the implementation details (solvers, kmeans , etc)

[aamijar]

Closing in favor of #1425