[petsc-dev] proposed minor PetscPartitioner changes

[Vaclav Hapla]

> 8. 11. 2017 v 14:52, Jed Brown <jed at jedbrown.org>:
> 
> Matthew Knepley <knepley at gmail.com <mailto: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.

Matt, do you mean what I wrote above is not true (then I'm going to prove that it's true), or the opposite that the PetscPartitionerPartition design is actually not good :-)

Vaclav

> 
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171108/632cdfcb/attachment.html>