> On Nov 10, 2017, at 8:51 AM, Vaclav Hapla <vaclav.ha...@erdw.ethz.ch> wrote: > > > >> 10. 11. 2017 v 14:56, Jed Brown <j...@jedbrown.org>: >> >> Vaclav Hapla <vaclav.ha...@erdw.ethz.ch> writes: >> >>>> 10. 11. 2017 v 5:09, Smith, Barry F. <bsm...@mcs.anl.gov>: >>>> >>>> >>>> >>>>> On Nov 8, 2017, at 3:52 AM, Vaclav Hapla <vaclav.ha...@erdw.ethz.ch> >>>>> wrote: >>>>> >>>>> >>>>>> 8. 11. 2017 v 9:06, Lisandro Dalcin <dalc...@gmail.com>: >>>>>> >>>>>> On 8 November 2017 at 05:51, Smith, Barry F. <bsm...@mcs.anl.gov> wrote: >>>>>>> >>>>>>>> On Nov 7, 2017, at 1:33 AM, Lisandro Dalcin <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. >>>> >>>> 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. >> >> Also known as COO format for a matrix. > > You could represent by COO any of the matrices above. I don't understand how > it relates to listing vertices and edges of a graph. > >> >>> 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. >> >> Matrix and graph are equivalent concepts. > > I think that's an overly strong statement. It sounds like a matrix and a > graph are bijectively interchangeable things which is certainly not true: > 1) As I mentioned, there are multiple ways of representing a graph by a > matrix, and for a given graphs these matrix representations don't even have > the same dimensions. > 2) Even if you stick to the adjacency matrix (which you apparently do), it's > still not bijective with the graph - the adjacency matrix is a square > symmetric Boolean matrix. You can just say that the _sparse pattern_ of the > _symmetric_ matrix is bijective with the respective graph. This is a by far > weaker statement. > > Why you then have a special matrix type MATMPIADJ which is value-less and > automatically symmetric if all matrices "are" graphs?
For efficiency. It is the format partitioning packages like and can use directly without any additional processing. > > Not talking about directed graphs, multigraphs, ... > > Vaclav > >> Mat is already extensible in >> the sense that it can have many representations. >> >>> (*) It's a similar problem as MatCreateVecs means to me "create a matrix of >>> Vecs type" according to usual convention. >> >> I think the key here is to look at the types. VecCreateFromMat() might >> be more clear in this context, but isn't clearly better. Alternatively, >> PetscCreateVec() and MatCreateVecs() would have this symmetry, but don't >> follow our usual prefix conventions.
