Suggest clarification of release note for 6.0

[Fabian188]

It is stated

* SuiteSparse/metis-5.1.0: renamed SuiteSparse_metis, to avoid confusion
    with the unmodified metis-5.1.0.  The compiled library is named
    libsuitesparse_metis.so.  The unmodified libmetis.so cannot be used
    with SuiteSparse.

but I think I also read somewhere else, that the modified libmetis.so is only required for Matlab. If so, I suggest to clarify. We statically link cholmod to a C++ application which already has metis linked to, this statement indicates complications or not :)

From the source I suggest, It would work without :)

[DrTimothyAldenDavis]

Those comments in the README are correct. METIS (more precisely, libsuitesparse_metis.so) is optional, both for MATLAB and for C/C++ applications.

CHOLMOD can use SuiteSparse_metis, and thus so can UMFPACK, SPQR, and KLU. All those packages can use metis if it's available, not just in MATLAB. If I have a statement somewhere else about metis only required for MATLAB, then it's out of date.

If you're using SuiteSparse (CHOLMOD, etc) with METIS in a C++ application, you'll need to switch from libmetis.so to libsuitesparse_metis.so. I can't use the unmodified libmetis.so which may come from a Linux distro, for example. I have to patch METIS in a minor way, but that means I'm unable to use the standard libmetis.so.

See the discussion here for more details: https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/SuiteSparse_metis/include/SuiteSparse_metis.h

[DrTimothyAldenDavis]

If you're using libmetis.so in your application, you can likely switch to my copy, libsuitesparse_metis.so. The main changes are:

(1) using a 64-bit integer (idx_t) (2) using the SuiteSparse malloc/calloc/realloc/free functions instead of the ANSI malloc/calloc/realloc/free. Those function pointers default to the ANSI C11 malloc/etc, but I need control over them for many applications.

THose changes are pretty tame in the sense that it should be easy to use libsuitesparse_metis in the rest of your application. Just know that the idx_t (as defined by SuiteSparse_metis.h) defines the idx_t as int64_t.

[DrTimothyAldenDavis]

But if those changes are too difficult, then just compile SuiteSparse without metis. You can do that with the NPARTITION setting passed to CMAKE_OPTIONS, or by just deleting the SuiteSparse_metis folder or renaming it, so then my cmake build process detects that it's not present, and then sets -DNPARTITION accordingly.

[Fabian188]

Thanks for the clarification. We link statically and have further libs that require metis. I need to test, if these work with your metis.

How do I set these cmake options when there is initially only a Makefile which builds all directly?

We can reorder ourselves before calling metis, so disabling metis within SuiteSparse might not be such of a performance penalty. Very nice to know of the option.

We integrate suitesparse (wrapped by very old cmake code) via cmake ExternalProject, which makes it easy to apply our default cmake setting when the initial configure is via cmake.

[DrTimothyAldenDavis]

You can do:

CMAKE_OPTIONS="-DNPARTITION" make

for example. Or you can edit the setting for CMAKE_OPTIONS at the top of the Makefile. I should put these instructions in the README.

[Fabian188]

Ah, I did not understand CMAKE_OPTIONS as environment variable, that makes it clearer.

Is there a way to control what is built? E.g. only need cholmod and umfpack and I guess I don't need e.g. graphblas and Mongoose?

[DrTimothyAldenDavis]

I've added this to the README (not yet in the master branch but will be soon):

https://github.com/DrTimothyAldenDavis/SuiteSparse/tree/dev2#compilation-options

To control what is built: this is why I don't have a single CMakeLists.txt script for all of SuiteSparse. Each package has its own. So to build a subset you can either comment out lines in the top-level Makefile, or do:

cd AMD ; make ; make install cd ../COLAMD ; make ; make install cd ../CHOLMOD ; make ; make install cd ../UMFPACK ; make ; make install

and so on.

[Fabian188]

We compile statically cholmod and umpfack automatically for various systems (including Windows) and different compilers.

Currently we use the very old SuiteSparse 4.2.1, April 25, 2013 where metis fails for larger systems on my Apple Silicon M1 system (btw. it is amazing how fast the arm-Macs compile and link!)

As our system is cmake based I'm currently unsure if to better switch to Sergui's cmake fork or to your original.

I need to wait for the feedback of a colleague who has Windows - for macOS your 6.0. beta works blazing fast with make static running in 12 seconds each for cholmod and umfpack.

[Fabian188]

Now I understand your statement "6.0.0 is cmake based": You provide all the Findxxx.cmake for easier usage via cmake and I was expecting cmake based building of the cmake source. Now it is clear to me :)

[DrTimothyAldenDavis]

I've changed how I handle METIS. It's now integrated into the libcholmod.(so,dll,dylib), rather than existing as a separate libsuitesparse_metis.so. This will avoid confusion with the standard libmetis.so (which I can't use) that may come with a Linux distro.

I safely rename the METIS functions so there's no change of CHOLMOD accidentally using the standard libmetis.so functions, in case you have an application that wants to use CHOLMOD, UMFPACK, and your own copy of METIS. You'll get 2 copies of METIS but they will safely coexist.

https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/CHOLMOD/Partition/cholmod_metis_wrapper.c https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/CHOLMOD/Partition/cholmod_metis_wrapper.h

[DrTimothyAldenDavis]

I think this is all OK now, so I'll close the issue - but let me know if there's some other issue remaining.