[petsc-dev] proposed minor PetscPartitioner changes

[Matthew Knepley]

On Wed, Nov 8, 2017 at 10:04 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch>
wrote:

>
> 8. 11. 2017 v 15:59, Matthew Knepley <knepley at gmail.com>:
>
> On Wed, Nov 8, 2017 at 9:14 AM, Vaclav Hapla <vaclav.hapla at erdw.ethz.ch>
> wrote:
>
>>
>> 8. 11. 2017 v 14:52, Jed Brown <jed at jedbrown.org>:
>>
>> 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.
>>
>>
>> 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 :-)
>>
>
> I meant "they must keep the same basic information just in two different
> forms" is wrong (I had to leave for work). The Section gives offsets for
> each partition, and the IS stores the actual points being sent.
>
>
> OK, now I see. And do you think the Section could be somehow computed from
> just the IS?
>

No, this is the right structure.

  Matt


> Thanks
>
> Vaclav
>
>
>    Matt
>
>
>> 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.
>>
>>
>>
>
>
> --
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which their
> experiments lead.
> -- Norbert Wiener
>
> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171108/1e6fa855/attachment.html>