<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 3, 2018 at 6:15 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">Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> writes:<br>
<br>
> On Tue, Apr 3, 2018 at 6:06 PM, Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Derek Gaston <<a href="mailto:friedmud@gmail.com">friedmud@gmail.com</a>> writes:<br>
>><br>
>> > Sounds great to me - what library do I download that we're all going to<br>
>> use<br>
>> > for managing the memory pool?  :-)<br>
>> ><br>
>> > Seriously though: why doesn't MPI give us an ability to get unique tag<br>
>> IDs<br>
>> > for a given communicator?<br>
>><br>
>> It's called a dup'd communicator.<br>
>><br>
>> > I like the way libMesh deals with this:<br>
>> > <a href="https://github.com/libMesh/libmesh/blob/master/include/" rel="noreferrer" target="_blank">https://github.com/libMesh/<wbr>libmesh/blob/master/include/</a><br>
>> parallel/parallel_<wbr>implementation.h#L1343<br>
>><br>
>> PETSc does something similar, but using attributes inside the MPI_Comm<br>
>> instead of as a wrapper that goes around the communicator.<br>
>><br>
>> <a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Sys/" rel="noreferrer" target="_blank">https://www.mcs.anl.gov/petsc/<wbr>petsc-current/docs/<wbr>manualpages/Sys/</a><br>
>> PetscCommGetNewTag.html<br>
>><br>
>> > I would definitely sign on for all of us to use the same library for<br>
>> > getting unique tag IDs... and then we would need a lot less<br>
>> communicators...<br>
>><br>
>> Communicators should be cheap.  One per library per "size" isn't a huge<br>
>> number of communicators.<br>
>><br>
><br>
> And this<br>
> <a href="https://experts.illinois.edu/en/publications/mpi-on-millions-of-cores" rel="noreferrer" target="_blank">https://experts.illinois.edu/<wbr>en/publications/mpi-on-<wbr>millions-of-cores</a> still<br>
> got published? I guess<br>
> the reviewers never wanted any more than 2K communicators ;)<br>
<br>
These are unrelated concerns.  A million is only 2^20 and 20 is much<br>
less thann 2000.  The issue is that communicator etiquette between<br>
libraries isn't expressed in some visible statement of best practices,<br>
perhaps even a recommendation in the MPI standard.  If hypre dup'd<br>
communicators like PETSc, then we would all have less code and it would<br>
be nowhere near 2000 even in the massive MOOSE systems.<br>
</blockquote></div><br>I understand. I was pointing out that even Bill went for the obvious target, rather</div><div class="gmail_extra">than the usability standard. And if they agreed with the last line, they should have pointed it out.</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>