> 10. 11. 2017 v 5:09, Smith, Barry F. <[email protected]>: > > > >> 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.
Yes. Mat can represent any graph in several different ways - e.g. Laplacian, adjacency, incidence, oriented incidence matrix. The graph could be also represented in other way like a list of vertices and edges. MatPartitioning picks just one representation as an input - the adjacency matrix. But I mean the picked representation does not matter, and the result is not a partitioning of any matrix, but partitioning of the graph. The graph is the underlying concept. This is why I don't consider the Mat prefix optimal. To me, the MatPartitioning prefix suggests either MatType MATPARTITIONING (*), or partitioned matrices (in a sense of block matrices, cf. https://en.wikipedia.org/wiki/Block_matrix). To be honest, I never thought MatPartitioning is meant to be so general until recently. But it's definitely nothing I would like argue much about :-) Thanks Vaclav (*) It's a similar problem as MatCreateVecs means to me "create a matrix of Vecs type" according to usual convention. > > 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
