[petsc-dev] proposed minor PetscPartitioner changes

Jed Brown jed at jedbrown.org
Wed Nov 8 07:52:12 CST 2017

Matthew Knepley <knepley at gmail.com> writes:

> On Wed, Nov 8, 2017 at 4:52 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch>
> wrote:
>> > 8. 11. 2017 v 9:06, Lisandro Dalcin <dalcinl at gmail.com>:
>> >
>> > On 8 November 2017 at 05:51, Smith, Barry F. <bsmith at mcs.anl.gov> wrote:
>> >>
>> >>> On Nov 7, 2017, at 1:33 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> >>>
>> >>> The only concern I have about PetscPartitioner is that the API depends
>> >>> on DM (PetscPartitionerPartition_<TYPE> routines). Maybe
>> >>> PetscPartitioner should eventually move to became more agnostic, and
>> >>> that way it can be used to partition matrices and meshes.
>> >>
>> >>   This is certainly a serious flaw if PetscPartitioner is intended as
>> THE API to use for partitioning. If it is not intended as THE API for
>> partitioning then that is also a problem, because why have multiple APIs
>> for what is essentially one set of abstractions.
>> >>
>> >
>> > Note however that things looks easy to refactor. I'll try to team up
>> > with Matt to improve things.
>> Wait, now we are at the beginning again. I actually wanted to do some
>> refactoring of PetscPartitioner, starting with few cosmetic changes to make
>> it better settable from options. But Barry kept me back of any edits since
>> he think it's anti-systematic to keep two independent classes doing
>> essentially the same. And I agree with that to be honest. It's strange to
>> have two ParMetis, two Scotch and two whatever interfaces. The only thing I
>> don't like on MatPartitioning is its name as it's not just for Mat
>> Partitioning :-)
>> There are from my point of view multiple issues with PetscPartitioner.
>> Let's look e.g. at PetscPartitionerPartition. It takes as arguments both
>> PetscPartitioner and DM. This DM must be in fact DMPlex which is not
>> checked so it will probably crash somewhere deep in the stack once the
>> first DMPlex specific line is reached. Then there are two output arguments
>> PetscSection partSection and IS *partition. The first must be created
>> beforehand while the second is created inside. And I guess they must keep
>> the same basic information just in two different forms.
> This is wrong.

Dude, this isn't how we interaction here.  If there is a technical
reason why what Vaclav, Lisandro, and Barry want to do cannot work, you
should explain that.  Just casting doubt without working toward a
solution is not okay.

More information about the petsc-dev mailing list