METIS vs scotchmetis and ParMETIS vs ptscotchparmetis
repartition.hh is the only place in the core modules using (Scotch)METIS or (Scotch)ParMETIS. There are currently some discussions in dune-common!822 (merged) and dune-common!821 (merged) whether the scotch variants should be dropped. This issues should provide some insights into this problem and tries to find a solution.
- Scotch implements the interface of some (Par)METIS functions, like
ParMETIS_V3_PartKway. It ships under the open-source license CeCILL-C (compatible to GPL(?))
- METIS is under the Apache License Version 2.0, while ParMETIS is distributed under a special license for educational, research, non-profit and US-agency use only.
- debian-free does not ship parmetis
- The interface of Scotch is compatible with METIS-4/5, while the interface of PTScotch seems to be compatible with ParMETIS-4
- ParMETIS, on the other hand, requires METIS >= 5
- METIS >= 5 introduces typedefs for its real and index types, see discussion in #45 (closed)
In summary: One can either use METIS-5 + ParMETIS-4, or Scotch + PTScotch. Not a mixup of scotch and METIS.
Scotch does not (in no version) provide the typedefs of METIS-5, but it is provided in several independent version for index types that makes it hard to configure.
Some more problems:
- Scotch-METIS is not fully compatible to METIS. In recent scotch version >= 6.0.7 you can select which METIS API you want to provide. Either API v3 or API v5. Both are not exactly the same as in METIS, but at least similar. Some function arguments even have a different meaning and the same values would result in completely different behaviour.
- PTScotch-ParMETIS is compatible to ParMETIS. There is only one API.
- PTScotch does not "export-C" its functions. This is a problem for using the library in C++ and introduces some restrictions on dependent libraries like MPI that, because of this, need to be provided for C and not for C++ plus lots of required platform dependent definitions
- Do we want to support the (pt)scotch interface at all?
- Do we want to assume that when calling
find_package(METIS)in cmake we silently can also get scotch (and correspondingly for ParMETIS and PTScotch)?
- Currently there is a workaround for the missing typedefs implemented in
dune/istl/repartition.hhonly, see MR !173 (merged) Do we want to provide a similar workaround for the general core modules? This seems reasonable, since the find package is provided with dune-common.
- Is there experience with scotch and ptscotch? Can someone test the changes in the cmake modules in dune-common!822 (merged) and dune-common!821 (merged)