Matthew Knepley <[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.
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.
