On Mon, Nov 6, 2017 at 8:34 AM, Smith, Barry F. <bsm...@mcs.anl.gov> wrote:
> > On Nov 6, 2017, at 7:27 AM, Matthew Knepley <knep...@gmail.com> wrote: > > > > On Mon, Nov 6, 2017 at 8:24 AM, Smith, Barry F. <bsm...@mcs.anl.gov> > wrote: > > > > Vaclav, > > > > Actually you should not just do this! PETSc already has a full > class for managing partitioning (that Matt ignored for no good reason) > > > > Obviously, a good reason existed. All sorts of horrible Mat-specific > crap was in these. > > Matt, > > There is no "Mat-specific crap" it in there. A Mat is used to represent > the graph (you do exactly the same thing in your horrible code, convert to > the matrix format that each external package uses, why have all the > duplicate code for no reason.) > > > It was impossible to use for mesh partitioning. > > Bullshit, you didn't even try. A useful comment if based on fact or experience. > > > In addition, > > when partitioning meshes, you need extra things (like calculation of the > dual graph), which is not used in the matrix case. > > MatPartitioning is NOT about partitioning MATRICES it is about > partitioning GRAPHS, so it can support anything related to graphs including > dual graphs etc. Again, you didn't even try to extend/improve MatPartioning > you just wrote all your own duplicative code, and not even particularly > well. > By "not particularly well, I assume there is some sort of deficiency there. However, I do not believe that there is. Matt > Once Vaclav takes a look at MatPartitioning he'll realize quickly he > can do a proper refactorization of all of the partitioning code that is > simpler and better. It is about time this rathole gets cleaned up. > > Barry > > > > > Matt > > > > > > see MatPartitioningCreate(). Please look at all the functionality before > doing anything. > > > > Any refactorization you do needs to combine, simplify, and cleanup > the two interfaces to create one simpler one. And please let us know your > design ideas (with for example an issue on bitbucket) before you go ahead > and write a lot of code we may end up not liking. > > > > Thanks for looking at this, > > > > Barry > > > > > > > On Nov 6, 2017, at 7:09 AM, Vaclav Hapla <vaclav.ha...@erdw.ethz.ch> > wrote: > > > > > > Hello > > > > > > The whole PetscPartitioner class sources are part of > > > src/dm/impls/plex/plexpartition.c, > mixed together with some DMPlex* functions. > > > If you don't mind, I would move the PetscPartitioner* stuff into the > separate file petscpartitioner.c > > > (in future, it could be even moved to a separate directory). > > > > > > I would also like to > > > * add PetscPartitioner{Add,Set,Get}OptionsPrefix, > > > * create the partitioner lazily in DMPlexGetPartitioner, followed by > PetscObjectIncrementTabLevel, PetscLogObjectParent and > PetscPartitionerSetOptionsPrefix calls, > > > * edit src/dm/impls/plex/examples/tutorials/ex5.c so that it calls > DMSetFromOptions right after DMPlexCreateFromFile, in order to make the > partitioner changeable from options. > > > > > > Do you have anything against? > > > > > > Vaclav > > > > > > > > > > -- > > 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/ > > -- 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/>