On Wed, Nov 8, 2017 at 1:49 PM, Jed Brown <[email protected]> wrote: > Matthew Knepley <[email protected]> writes: > > >> > No, this is the right structure. > >> > >> Oh come on. You're defending a quadratic algorithm. > >> > >> ierr = ParMETIS_V3_PartKway(vtxdist, xadj, adjncy, vwgt, adjwgt, > >> &wgtflag, &numflag, &ncon, &nparts, tpwgts, ubvec, options, &edgeCut, > >> assignment, &comm); > >> // ... > >> for (p = 0, i = 0; p < nparts; ++p) { > >> for (v = 0; v < nvtxs; ++v) { > >> if (assignment[v] == p) points[i++] = v; > >> } > >> } > >> > >> MatPartitioningApply creates an IS with "assignment" and can be > >> converted to a global numbering with ISPartitioningToNumbering. You > >> could as well have an ISPartitioningToSectionAndIS() that produces your > >> representation, preferably without this silly quadratic algorithm. > >> > > > > Time it. Tell me if it matters. Telling me it matters in the long run is > > metaphysics. > > I realize ParMETIS isn't scalable and that if you have a modest number > of parts and only a million or so elements per rank, the cost of what > you do here will be acceptable for most uses. > > But you didn't refute my point that ISPartitioningToSectionAndIS can > produce the representation you want.
I do not think its an either or thing. Many equivalent interfaces are possible, so I should have told Vaclav "I think this is the right one", but I thought that was implicit in me being the responder, and none of us thinking that there is a true "right" in interface design. > The IS you're creating is similar > to the inverse of the Numbering (which is a permutation). You are the > one that replaced a scalable algorithm that has existed for a long time > and uses types correctly with PetscPartitioner which has some ugly > warts, duplicates a lot of code, and isn't a viable replacement for > MatPartitioning. 1) MatPartitioning is not a replacement for what I do. According to you, that should end the argument right there. 2) Deep inside MatPartitioning, it must split things up as I do in order to pack stuff to be sent. I think it should be exposed as I have done. 3) I think you exaggerate the faults of the code for effect. Do what you must. > And now you seem to be arguing against Vaclav unifying > it, claiming technical rationale that don't appear to hold up. Of course, I disagree with you, and think you make no attempt to understand why someone would write this code, because you never solve the problems its necessary for. > I don't > understand why, but it certainly looks like PetscPartitioner can be > implemented as a thin layer around MatPartitioning, then that layer can > be refactored into helper functions at the IS/PetscSection level. It might be true. To me, it looked like Mat stuff was draped on so it would be hard to pull the raw result out of the partitioner, and that things would get created (like the MatMult Scatter) which I did not want. Matt > If > there is a solid technical reason why this is fundamentally poor design, > please explain so we can figure out a better design. > -- 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/>
