[petsc-dev] petsc-dev post from tabrezali at gmail.com requires approval

[Smith, Barry F.]

  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 <jed at jedbrown.org> wrote:
> 
> Lisandro Dalcin via petsc-dev <petsc-dev at mcs.anl.gov> 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.