single precision sparse matrices for CHOLMOD, UMFPACK, and SPQR

[DrTimothyAldenDavis]

I'm working on an update to CHOLMOD, UMFPACK, and SPQR that will add support for sparse single precision (float) matrices to those 3 packages. The first package, CHOLMOD, will be updated first.

The new CHOLMOD wil need to be be v5.0 since there are some changes to the API that allow for float and float complex matrices to be added. The new API will be nearly entirely backward-compatible with v4.2, but there is at least one change in a user-visible struct that will differ. However, I don't expect that any downstream packages will care (Common->xworksize becomes Common->xworkbytes, and its meaning changes from # of doubles in the Common->Xwork workspace to the # of bytes in the same space (so it can now be a float array).

I don't expect any downstream packages actually look at this value, since it's managed by CHOLMOD on its own. So most packages should be able to link with v5.0 without even needing to recompile their packages.

However, since this is a visible binary change, CHOLMOD needs to bump to v5.0, and the safest thing will thus be to recompile any downstream packages that use it.

I'm not ready to post this update to CHOLMOD yet, but I can likely post a draft on a new branch in a few weeks days (Oct 22 update: it was closer than I thought).

Let me know in this discussion thread if you have any questions about the upcoming changes. Stay tuned!

[DrTimothyAldenDavis]

See the new branch: https://github.com/DrTimothyAldenDavis/SuiteSparse/tree/single .

CHOLMOD v5 deletes the CHOLMOD:Core module and replaces it with the new CHOLMOD:Utility module, with support for sparse single precision matrices. However, the rest of CHOLMOD has not yet been updated with support for single precision (float) matrices. CHOLMOD:Utility has the same user API as CHOLMOD:Core, it's just been completely rewritten underneath.

It's a branch off of dev, not dev2, because I will need to release this as a stable CHOLMOD 5.0.0 and SuiteSparse 7.3.0 soon. So v7.3.0 will be essentially identical to SuiteSparse 7.2.2, except for CHOLMOD. It will use the same build system, and it doesn't include the new packages (ParU and LAGraph) that are not ready to release.

There are some minor changes to the KLU, GPUQREngine, UMFPACK and SPQR, because of the version change of CHOLMOD. I will add this new CHOLMOD v5 to the dev2 branch, and the minor tweaks to KLU, etc, except I'll keep all the latest cmake updates in dev2.

If I make any further changes to the CHOLMOD source in the 'single' branch, I'll keep it up to date in dev2 as well.

[DrTimothyAldenDavis]

I've updated the dev2 branch with CHOLMOD 5.0.0 and the new CHOLMOD:Utility Module. This draft CHOLMOD is fully functional and passes all my rigorous tests in CHOLMOD/Tcov. Support for single precision sparse matrices is not yet complete (it appears in CHOLMOD/Utility but is not yet supported by the other Modules).

So any additional changes made to the dev2 branch for the cmake build system updates should work just fine.

[DrTimothyAldenDavis]

CHOLMOD 5.1.0 is now in the default dev branch, where it's working fine with the SuiteSparse 7.3 build system. The latest build system with major updates from @mmuetzel is still in progressing in the SuiteSparse/dev2 branch, but getting close to release, I think.

I could either release CHOLMOD 5.1.0 in SuiteSparse 7.4.0.beta1 now, using the build system currently in SuiteSparse/dev (without ParU and LAGraph as well), or I could wait until all of the latest updates in SuiteSparse/dev2 are ready to release (which would then become SuiteSparse 7.5 when that's ready to go).

[mmuetzel]

CHOLMOD 5.1.0 is now in the default dev branch, where it's working fine with the SuiteSparse 7.3 build system. The latest build system with major updates from @mmuetzel is still in progressing in the SuiteSparse/dev2 branch, but getting close to release, I think.

I'd also guess that the build system changes are close to being finished. I'm only having some documentation changes for it in mind.
It's probably still not perfect. But I'd guess that it would be good enough for a release. I guess for the most common configurations we have CI in place now. There shouldn't be regressions with respect to the existing build system. (But there's no perfect certainty.) If users run into issues for their specific use cases, we could still tackle them in minor releases if that is fine with you.

I could either release CHOLMOD 5.1.0 in SuiteSparse 7.4.0.beta1 now, using the build system currently in SuiteSparse/dev (without ParU and LAGraph as well), or I could wait until all of the latest updates in SuiteSparse/dev2 are ready to release (which would then become SuiteSparse 7.5 when that's ready to go).

Are you only waiting for the build system changes? Or do you still have changes/reviewing for the new libraries in your pipeline?

[DrTimothyAldenDavis]

CHOLMOD 5.1.0 is ready to go, as is the tiny change to AMD and CAMD related to that change.

For the other packages: it depends.

• ParU needs some polishing, and I may need to tweak the API. This will take me a while. One option would be to release it anyway as-is, but drop the version to 0.1.
• UMFPACK needs minor work (I'm still using amd_internal.h).
• GraphBLAS 8.x vs 9.x is a bottleneck, unrelated to the build system. I'd like to move to GraphBLAS 9.x but I must wait for the v2.1 API to be formally released (https://github.com/GraphBLAS/graphblas-api-c). I could go with the current GraphBLAS 8.2.1 in dev, and just bump the version number to 8.3.0 with the new build system.
• LAGraph has the same bottleneck as GraphBLAS. My draft LAGraph (here: https://github.com/GraphBLAS/LAGraph/tree/v1.1) relies on GraphBLAS 9.x. So if I release our new build system in SuiteSparse soon, I would need to keep the current LAGraph in SuiteSparse, and just bump its version number. I would call the current SuiteSparse/LAGraph v1.1 (since it has the new feature: a much better build system), and then call the draft LAGraph (https://github.com/GraphBLAS/LAGraph/tree/v1.1) as v1.2 instead, when it's ready to update in SuiteSparse. In either case, I can't release a formal version of LAGraph without getting feedback from the LAGraph community (even a 1.0.2 release with the new build system and no other changes). This could take a while. I can't do that until the new build system is mostly stable.

All the other packages are fine. All I would need to do in the SuiteSparse dev2 branch is to update their version numbers, Doc/ChangeLog, and the various user guides. Each version number x.y.z would bump to x.(y+1).0, since adding the new build system is not a patch (z+1) but a major new feature (y+1). It's not a x+1 bump because all of the packages are binary compatible with the currently released versions.

[mmuetzel]

I opened #537 with the documentation change I was thinking about.
Afaict, no major changes to the build system are still pending that I can think of currently. (The only thing somewhat related to the build system might be converting more demos to ctests. But that's probably out of my league admittedly. I could still help with some platform-specific patches though if you'd like.)

If the need to fix bugs in the build system arises, the necessary changes will hopefully be small.
I tried to still allow linking LAGraph to other versions of GraphBLAS. But I didn't actually try if that works. Please, let me know if there are issues with that (or any other parts).
Other than that, the changes might be stable enough to start synchronizing with the upstream community of LAGraph (if they like).

[DrTimothyAldenDavis]

OK. Let's do this, then.

I will use the new build system in dev2 for the next release, SuiteSparse 7.4.0. It will have:

• (1) ParU, nearly as-is, but version 0.1. I can then polish it later.
• (2) CHOLMOD 5.1.0, with the new single precision support, plus the new build system, and the new ctest.
• (3) AMD 3.3.0 and CAMD 3.3.0, with the current tweak in 3.2.2, plus the new build system
• (4) GraphBLAS 8.3.0, which would be the same as the current dev2/SuiteSparse/GraphBLAS but with the new build system, and the new cmake for the JITPackage. Also the GB_atomics.h update. Otherwise no major changes (those will be 9.x). This way, I can make progress without getting held up by the release of the stable v2.1 C API.
• (5) LAGraph 1.1.0, like GraphBLAS: major change is the build system. I will need to get approval from the LAGraph committee, and then update the primary LAGraph repo with this new v1.1.0. I will rename my draft v1.1 in the LAGraph repo as v1.2 and release it when GraphBLAS 9.0 is ready (when the v2.1 C API is done)
• (6) SPEX will be 2.3.0, and then sometime after SuiteSparse 7.4.0 is released, I will update this to SPEX 3.1.0 by combining the v3.0 release at https://github.com/clouren/SPEX with the new build system, to get SPEX v3.1.0, to appear in SuiteSparse v7.5.0.
• (7) all other packages: versions will bump from their current x.y.z to x.(y+1).0, with the new build system.

I think I can take care of all of that.

For the conversions of the demos into ctests: yes, I'll need to do that, but it can wait until SuiteSparse 7.5. I'll ping you if I get stuck (like how I got stuck with CHOLMOD on MSVC). But with the CHOLMOD ctests added, I can hopefully mimic the same structure for the other codes.

Does that sound like a plan?

Thanks again for all your help. The new build system is great.

[mmuetzel]

I've made some progress with CUDA on Windows. See https://github.com/mmuetzel/SuiteSparse/tree/ci
But I'm currently stuck because there is a cyclic dependency between libcholmod and libcholmod_cuda: cholmod_l_gpu_allocate in libcholmod_cuda depends on cholmod_l_error that is exported by libcholmod. And libcholmod already depends on libcholmod_cuda (if CUDA is available).

One possible solution could be to absorb the entirety of libcholmod_cuda into libcholmod (if CUDA is available). That is, still keep the separate folder and CMake file. But link those objects into libcholmod instead of a separate library.

Would that be ok?

[DrTimothyAldenDavis]

Yes! I wanted to do that but was unable to get the cmake scripts to do that. So I settled on putting the cuda stuff in its own library.

A single library would be much better. I had that when using just "make" but failed to do it in cmake

[mmuetzel]

I'm getting problems with a similar cyclic dependency between libspqr and libspqr_cuda now.
Would it be ok to merge those into a single library, too?

[DrTimothyAldenDavis]

Yes that would be awesome!

[mmuetzel]

I opened #556 with a change that combines libspqr_cuda with libspqr.

[DrTimothyAldenDavis]

Making progress: I have merged all of dev2 into dev, so now all the latest updates (your new build system, my single CHOLMOD, etc) are synced in the default branch.

CUDA on MSVC is a real mess. Lots of things that I require from CUDA (for GraphBLAS at least) are in Linux but are not yet ported to Windows, so it might not work at all, until a future release of CUDA itself. I'm collaborating with NVIDIA on CUDA for GraphBLAS and CHOLMOD, and I can ask them for help, too. The primary CUDA work for GraphBLAS is currently here, in the draft GrB v9.0.1: https://github.com/DrTimothyAldenDavis/GraphBLAS/tree/dev2 which is very different from the v8.3.0 in SuiteSparse.

I need to sync the latest updates to the GraphBLAS build system in v8.3.0 with v9.0.1 in that repo. At some point I'll transition to doing all of my latest GraphBLAS work in one place (in this repo).

[DrTimothyAldenDavis]

CHOLMOD 5.1.0 is now in SuiteSparse 7.4.0.beta1, and appears as a pre-release.

[DrTimothyAldenDavis]

CHOLMOD 5.1.1 appears in SuiteSparse 7.5.0 (a stable release). It's essentially finished, in terms of support for single precision. It could use a method for creating a copy of a sparse matrix, dense matrix, triplet matrix, or factorization, while at the same time converting between single and double precision (see issue #720, which I'll consider for a future version of CHOLMOD), but otherwise it's in good shape.

UMFPACK and SPQR are still double-precision only (real & complex). I'll tackle them in the future.