[petsc-dev] proposed minor PetscPartitioner changes

[Matthew Knepley]

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.

   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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20171108/15e345d5/attachment.html>