> On Nov 8, 2017, at 3: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.
Strange is not the word, f***up is the word > 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. > > 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, Why? What is wrong with Mat? Mat can represent any graph and graphs are always what partitioning packages actually partition. I don't see a reason for a different name. MatPartitioner does not, nor should it, directly partition meshes etc, those can/should be done by; the proper massaging of data, the creation of a MatPartitioner object, calling the partitioner and then using the result of the partitioner to build whatever appropriate data structures are needed for the mesh partitioner. Barry > - 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 >
