> 8. 11. 2017 v 15:59, Matthew Knepley <knep...@gmail.com>: > > On Wed, Nov 8, 2017 at 9:14 AM, Vaclav Hapla <vaclav.ha...@erdw.ethz.ch > <mailto:vaclav.ha...@erdw.ethz.ch>> wrote: > >> 8. 11. 2017 v 14:52, Jed Brown <j...@jedbrown.org >> <mailto:j...@jedbrown.org>>: >> >> Matthew Knepley <knep...@gmail.com <mailto:knep...@gmail.com>> writes: >> >>> On Wed, Nov 8, 2017 at 4:52 AM, Vaclav Hapla <vaclav.ha...@erdw.ethz.ch >>> <mailto:vaclav.ha...@erdw.ethz.ch>> >>> wrote: >>> >>>> >>>>> 8. 11. 2017 v 9:06, Lisandro Dalcin <dalc...@gmail.com >>>>> <mailto:dalc...@gmail.com>>: >>>>> >>>>> On 8 November 2017 at 05:51, Smith, Barry F. <bsm...@mcs.anl.gov >>>>> <mailto:bsm...@mcs.anl.gov>> wrote: >>>>>> >>>>>>> On Nov 7, 2017, at 1:33 AM, Lisandro Dalcin <dalc...@gmail.com >>>>>>> <mailto:dalc...@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? 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/>