None of this matters because PetscPartitioner is due to be gutted and its functionality provided by calls to MatPartitioning. All improvements to managing calls to the underly partitioners should be made to MatPartioning. Barry
On Aug 28, 2019, at 7:53 AM, Jed Brown <[email protected]> wrote:
Lisandro Dalcin via petsc-dev <[email protected]> writes:
If this line was protected with #if defined(PETSC_HAVE_METIS) and PETSc was not installed with ParMetis, but only Metis would the code run correctly? Or is it somehow that even though you are only using metis here you still need parmetis? For what reason?
With some code changes, it would be possible to support PETSc with METIS and no ParMETIS, but that would only cover a special (though frequent) case (partitioning an initially sequential mesh), and the PetscPartitioner type name is "parmetis", so that would be confusing. I think it is not really worth it to make these changes.
I recall Jack observing that sequential METIS often outperformed (in time) ParMETIS for nested dissection ordering in Elemental's sparse solvers. This isn't trivial since we'd need to implement gathering to one process and scattering the results back, but it's something to consider if we add support for calling METIS directly.