<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 8, 2017 at 1:02 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"><div class="HOEnZb"><div class="h5">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Wed, Nov 8, 2017 at 10:04 AM, Vaclav Hapla <<a href="mailto:vaclav.hapla@erdw.ethz.ch">vaclav.hapla@erdw.ethz.ch</a>><br>
> wrote:<br>
><br>
>><br>
>> 8. 11. 2017 v 15:59, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>>:<br>
>><br>
>> On Wed, Nov 8, 2017 at 9:14 AM, Vaclav Hapla <<a href="mailto:vaclav.hapla@erdw.ethz.ch">vaclav.hapla@erdw.ethz.ch</a>><br>
>> wrote:<br>
>><br>
>>><br>
>>> 8. 11. 2017 v 14:52, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>>:<br>
>>><br>
>>> Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
>>><br>
>>> On Wed, Nov 8, 2017 at 4:52 AM, Vaclav Hapla <<a href="mailto:vaclav.hapla@erdw.ethz.ch">vaclav.hapla@erdw.ethz.ch</a>><br>
>>> wrote:<br>
>>><br>
>>><br>
>>> 8. 11. 2017 v 9:06, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>>:<br>
>>><br>
>>> On 8 November 2017 at 05:51, Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
>>><br>
>>><br>
>>> On Nov 7, 2017, at 1:33 AM, Lisandro Dalcin <<a href="mailto:dalcinl@gmail.com">dalcinl@gmail.com</a>> wrote:<br>
>>><br>
>>> The only concern I have about PetscPartitioner is that the API depends<br>
>>> on DM (PetscPartitionerPartition_<<wbr>TYPE> routines). Maybe<br>
>>> PetscPartitioner should eventually move to became more agnostic, and<br>
>>> that way it can be used to partition matrices and meshes.<br>
>>><br>
>>><br>
>>>  This is certainly a serious flaw if PetscPartitioner is intended as<br>
>>><br>
>>> THE API to use for partitioning. If it is not intended as THE API for<br>
>>> partitioning then that is also a problem, because why have multiple APIs<br>
>>> for what is essentially one set of abstractions.<br>
>>><br>
>>><br>
>>><br>
>>> Note however that things looks easy to refactor. I'll try to team up<br>
>>> with Matt to improve things.<br>
>>><br>
>>><br>
>>> Wait, now we are at the beginning again. I actually wanted to do some<br>
>>> refactoring of PetscPartitioner, starting with few cosmetic changes to<br>
>>> make<br>
>>> it better settable from options. But Barry kept me back of any edits since<br>
>>> he think it's anti-systematic to keep two independent classes doing<br>
>>> essentially the same. And I agree with that to be honest. It's strange to<br>
>>> have two ParMetis, two Scotch and two whatever interfaces. The only thing<br>
>>> I<br>
>>> don't like on MatPartitioning is its name as it's not just for Mat<br>
>>> Partitioning :-)<br>
>>><br>
>>> There are from my point of view multiple issues with PetscPartitioner.<br>
>>> Let's look e.g. at PetscPartitionerPartition. It takes as arguments both<br>
>>> PetscPartitioner and DM. This DM must be in fact DMPlex which is not<br>
>>> checked so it will probably crash somewhere deep in the stack once the<br>
>>> first DMPlex specific line is reached. Then there are two output arguments<br>
>>> PetscSection partSection and IS *partition. The first must be created<br>
>>> beforehand while the second is created inside. And I guess they must keep<br>
>>> the same basic information just in two different forms.<br>
>>><br>
>>><br>
>>> This is wrong.<br>
>>><br>
>>><br>
>>> Matt, do you mean what I wrote above is not true (then I'm going to prove<br>
>>> that it's true), or the opposite that the PetscPartitionerPartition design<br>
>>> is actually not good :-)<br>
>>><br>
>><br>
>> I meant "they must keep the same basic information just in two different<br>
>> forms" is wrong (I had to leave for work). The Section gives offsets for<br>
>> each partition, and the IS stores the actual points being sent.<br>
>><br>
>><br>
>> OK, now I see. And do you think the Section could be somehow computed from<br>
>> just the IS?<br>
>><br>
><br>
> No, this is the right structure.<br>
<br>
</div></div>Oh come on.  You're defending a quadratic algorithm.<br>
<br>
      ierr = ParMETIS_V3_PartKway(vtxdist, xadj, adjncy, vwgt, adjwgt, &wgtflag, &numflag, &ncon, &nparts, tpwgts, ubvec, options, &edgeCut, 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>
</blockquote></div><br>Time it. Tell me if it matters. Telling me it matters in the long run is metaphysics.</div><div class="gmail_extra"><br></div><div class="gmail_extra">   Matt<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>