Discussion: Metis External Program Support

Metis Support

This follows on from the discussion on MR !2439 (closed)

Octopus's cmake currently does not support building our internal version of metis. As metis is considered a core requirement of Octopus, we should consider:

  • Enable fetching and building of metis from source
  • Support the build of internal metis as the fallback if metis is not found on the system

Problems with Internal Metis

  • Octopus's internal copy of metis contains source modifications - not documented
  • Currently no option to build this with Octopus's cmake build systems

Comments in Autotools

# METIS is only useful in parallel.
# To compile ParMETIS, you needed external METIS. So, no point in depending on internal METIS here.

This raises the questions:

  • If comment 1 is correct, then for non-MPI compilation, metis is not a hard requirement: Why can't we fall back to hilbert?
  • If comment 2 is correct, why are we carrying around an internal copy of metis? It only makes sense if comment 1 is wrong
  • If comment 2 is correct, @LecrisUT's assertion that we should make the effort to support the external metis/parametis project is a priority over implementing cmake support for internal metis, because all packaging will likely move to this version

Some Questions

If the autotools source comments are wrong (i.e. metis is advantageous even in serial), we should support the build of internal metis with our cmake build system. As metis has only had minor version bumps in the past 10 years, this seems reasonable.

Else, if metis is only useful with parametis, why not change the serial default? This reduces requirements on external packages with no loss of performance.

Octopus does not carry parametis. If we use parametis we ignore the internal version of metis (if the autotools comment is correct) - does this mean that the internal Octopus changes can safely be discarded?

As parametis is required for MPI performance, and this is undoubtedly performant, this implies we are still dependent on the upstream metis, as well as parametis and should consider exactly what we require from upstream metis

Issues with Upstream Metis

Fetching metis 5.1.0 from tar isn't currently viable because the package won't build with Octopus out of the box:

  • GKLib dependency is unknown
  • Linkage to GKLib assumes it is installed in a GKLIB_PATH
  • Metis sets various compile flags etc. globally using non-namespaced options
  • IDXTYPEWIDTH is not exposed
  • The build system of METIS is not CMake, it's Makefile calling CMake

@LecrisUT asserts that the upstream version is not compatible with Octopus due to Octopus relying on a patched version (if that's that case, I don't understand how we're currently relying on any external version of metis?).

Metis 5.2.1

The source available from Github is fundamentally broken, and will seg fault upon execution.

Reiterating the main points:

  • Is serial metis more performant that no metis?
  • What is patched in Octopus's internal metis? How can we use an internal version and an external version if there's some incompatible difference?
  • Will parametis build ontop of Octopus's internal metis? If not, then the internal version is creating more problems than solutions and we do need to support some upstream version
Edited by Alex Buccheri