-
Notifications
You must be signed in to change notification settings - Fork 277
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop internal copy of METIS #291
Comments
Thanks for the update. I'll take a look. I might still need to keep my own renamed copy of METIS, because of the definition of the METIS index type. I need to revise it to int64_t, which follows the instructions in the METIS include file, but it means that my revision would conflict with an unmodified METIS. If METIS 5.2.1 fixes that issue, then going back to an unmodified (64-bit capable) METIS would be fine. Otherwise, I'll have to stick with my modified version -- perhaps as a modification of METIS 5.2.1. |
I investigated this further and I think your issue is not fixed. Further GKlib was spun off and has become a dependency of METIS, but there was no proper release for GKlib (1, 2). If possible it would be good to have your diff somewhere documented, maybe we can create a merge request to METIS, and hope that we can convince Prof. George Karypis to include it upstream |
My diff is very short, but it's not a complete fix for these various METIS issues. I #include only the subset of METIS (GKlib and libmetis) that I need. I leave out features in GKlib that are not very portable (requiring POSIX for example) that are only needed for the METIS stand-alone programs. Perhaps you've seen this already: You see the commented out #include's are files in METIS that I don't use, and thus those files are unmodified from the original. Here's the output of a diff between the original metis-5.1.0 and my SuiteSparse/CHOLMOD/SuiteSparse_metis folder, from:
Gives this result below. I see though that I can trim the diff further. For example, I figured out that I do not need the GKlib/csr.c file at all, so it is now disabled in the cholmod_metis_wrapper.c. But I have an
That's my entire set of changes to METIS. This strategy keeps my edits of METIS very terse, but it means that they are not a complete fix for all of the various METIS issues I've encountered. |
I have a cmake script that detects if ssize_t is available, and then I #define NO_SSIZE_T accordingly. The script is in SuiteSparse_config/cmake_modules. That's a better technique than the logic in the METIS file itself but it means my fix for METIS would require that cmake script. |
I've removed my edits to csr.c, pdb.c, and graph.c, reverting to the METIS 5.1.0 originals, in my dev2 branch. I'll see about integrating METIS 5.2.1 into my SuiteSparse_metis variant. It's likely there are tweaks I had to make to METIS 5.1.0 that are now resolved in that version. The main issues I've had with METIS are: (1) size of the index type. I require 64 bits. This can be changed by editting the metis.h file, per the instruction in METIS, but then the resulting library conflicts with a default 32-bit build. METIS needs to use a different name space for 64-bit functions but it doesn't do that. So I have to keep my METIS revision private, to avoid conflicting with a default METIS that might be installed alongside SuiteSparse. (2) memory functions. I require the use of alternative malloc/calloc/realloc/free functions. METIS doesn't support this, so I've editted GKlib.h to insert my own. I also must disable the setjmp/longjmp and gkmcore. (3) signals. I can't let METIS raise signals since that breaks MATLAB. Throwing errors with signals, or modifying signal handlers, breaks all kinds of things, and METIS shouldn't have to do that. It throws a signal if it runs out of memory, which is a really awful thing to do to the applications that use SuiteSparse. (4) portability problems: these could be fixed in the METIS upstream, but I have lots of problems with things like ssize_t, regex, Windows __declspec's, and other issues in files that I'm no longer using. I've fixed most of these in my use of METIS. I still let METIS raise a signal if it's not inside MATLAB but I try to ensure this never happens by pre-allocating enough memory that I think METIS will use (before I call METIS) and then freeing it. See SuiteSparse/CHOLMOD/Partition/cholmod_metis.c Line 166 in 42de2d8
If that works, there's a good chance the memory will be there for METIS. It's not a complete solution. A complete solution would be to use a robust memory-error handling design in METIS itself: if malloc fails, free any workspace allocated so far, and return an "out of memory" flag to the caller. I do this in all of SuiteSparse and it works just fine, if done right. METIS is a great package ... which is why I use it in spite of these quirks. I just have to work around the quirks. |
I have other workarounds too, to avoid some bugs that might now be fixed: SuiteSparse/CHOLMOD/Partition/cholmod_metis.c Line 722 in 42de2d8
|
I had quite some issues with the current Metis for non-SuiteSparse use. I had to stick to 5.1. I don't remember the issues, IIRC it was compiling on Windows and runtime behavior on Linux. I just want to suggest to be careful with switch there. |
Thanks for the heads up. |
I'm going to keep my internal copy of METIS. It's safe, since I don't conflict with the original METIS namespace (I rename all the functions) and I don't create any libmetis.so. None of my compiled METIS functions are visible to the user. Using my own internal METIS allows me to revise/fix various issues (see the discussion above). I will evaluate METIS 5.2.1 in the future, but for now I'll stick with my copy of v5.1. |
In December 2022 METIS 5.2.1 has been released. This might solve some of the problems, SuiteSparse try to work around by providing its own modified copy of METIS.
Packaging SuiteSparse with its own copy of METIS is a burden for package maintainers.
The text was updated successfully, but these errors were encountered: