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