> 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.

> 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.

   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/

Reply via email to