Added support for ParMETIS with `real_t != float`
This MR fixes #45 (closed)
Starting with version ParMETIS 4.0 the typedef
real_t is introduced to allow different floating-point types for e.g. weights depending on the macro
REALTYPEWIDTH. Also, the typedef
idx_t is introduced to specify the integer type of indices, depending on the macro
IDXTYPEWIDTH. Now, the corresponding typedefs are used instead of fixing the types to
When (PT)Scotch(Par)METIS is used, the index type is given by
SCOTCH_Num, while the floating-point type is fixed to
- Added namespace
- Added typedefs
idx_tin namespace Metis, depending on configuration (with parmetis, with scotchmetis, or without). These names follow the original names introduced in the Metis library.
- Changed all occurences of
floatin the signature of parmetis calls to
Some users prefer the Scotch library over ParMETIS due to license restrictions. But, unfortunately, up to now the
parmetis.h provided by Scotch are not self-containing, i.e. the defined interfaces rely on a type
SCOTCH_Num that is not defined in
metis.h. Thus, Scotch need to be patched in order to to be usable in the same way as Metis and ParMetis.
Problem: There is no common way to patch the library. Everyone makes it differently. In Debian 9, there is no
SCOTCH_Num introduced, but simply the interface rewritten with explicit types. In Debian 10, the file
scotch.h is included inside
metis.h. In the patch provided by @markus.blatt a typedef was introduced in
parmetis.h. One can not detect, by looking in the header file, what kind of patch is implemented.
Proposed solution: By default, Scotch uses
SCOTCH_Num type. So, I stick on this. Only if the user sets
-DHAVE_SCOTCH_NUM_TYPE I use
SCOTCH_Num. So, it compiles as before, but gives additional flexibility. Maybe one can add a cmake compile-test to find out whether
SCOTCH_Num is provided or not.