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