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. > > Actually the original problem I wanted to solve is that > src/dm/impls/plex/examples/tutorials/ex5.c fails with partitioner set to > PETSCPARTITIONERPARMETIS for certain numbers of processes, see below. Let > me start with pull request altering ex5.c so that partitioner type can be > set from options properly and this bug can be reproduced easily. > [ 0] ***ASSERTION failed on line 176 of file /scratch/petsc-dev/arch-linux- > gcc-salvus/externalpackages/git.parmetis/libparmetis/comm.c: j == nnbrs > [ 2] ***ASSERTION failed on line 176 of file /scratch/petsc-dev/arch-linux- > gcc-salvus/externalpackages/git.parmetis/libparmetis/comm.c: j == nnbrs > ex5: /scratch/petsc-dev/arch-linux-gcc-salvus/externalpackages/ > git.parmetis/libparmetis/comm.c:176: libparmetis__CommSetup: Assertion `j > == nnbrs' failed. > ex5: /scratch/petsc-dev/arch-linux-gcc-salvus/externalpackages/ > git.parmetis/libparmetis/comm.c:176: libparmetis__CommSetup: Assertion `j > == nnbrs' failed. > Okay, it would be great to get a test base and knock this one out. Thanks, Matt > I'm wondering whether the MatPartitioning interface has the same problem. > But anyhow I mean it's maybe time to decide about the two interfaces before > chasing all these PetscPartitioner issues. > > I propose > - to rename Mat Partitioning to just Partitioning/-er or take over the > name PetscPartitioner, > - what is now PetscPartitioner would be MeshPartitioning/-er and it would > become sort of adapter from DMPlex meshes to general graphs so that the > more general class above can be employed. > > Note that I created an issue request as Barry suggested (#192) but there's > no feedback yet. > > Note my top level intention is to chip in some more distributed mesh > loaders - currently there's only one for Salome/MED format which is rather > non-standard and not much documented. > > Thanks > > Vaclav > > > > > > > -- > > Lisandro Dalcin > > ============ > > Research Scientist > > Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) > > Extreme Computing Research Center (ECRC) > > King Abdullah University of Science and Technology (KAUST) > > http://ecrc.kaust.edu.sa/ > > > > 4700 King Abdullah University of Science and Technology > > al-Khawarizmi Bldg (Bldg 1), Office # 0109 > > Thuwal 23955-6900, Kingdom of Saudi Arabia > > http://www.kaust.edu.sa > > > > Office Phone: +966 12 808-0459 > > -- 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/>
