> 8. 11. 2017 v 14:52, Jed Brown <[email protected]>: > > Matthew Knepley <[email protected] <mailto:[email protected]>> writes: > >> On Wed, Nov 8, 2017 at 4:52 AM, Vaclav Hapla <[email protected]> >> wrote: >> >>> >>>> 8. 11. 2017 v 9:06, Lisandro Dalcin <[email protected]>: >>>> >>>> On 8 November 2017 at 05:51, Smith, Barry F. <[email protected]> wrote: >>>>> >>>>>> On Nov 7, 2017, at 1:33 AM, Lisandro Dalcin <[email protected]> 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.
