<div dir="ltr"><div>It looks nice for me. <br><br></div>Fande,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 3, 2018 at 3:04 PM, Stefano Zampini <span dir="ltr"><<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">What about<div><br></div><div>PetscCommGetPkgComm(MPI_Comm comm ,const char* package, MPI_Comm* pkgcomm)<div><br></div><div>with a key for each of the external packages PETSc can use?</div><div><div class="h5"><div><br></div><div><br><div><blockquote type="cite"><div>On Apr 3, 2018, at 10:56 PM, Kong, Fande <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> wrote:</div><br class="m_-7476549295757753627Apple-interchange-newline"><div><div dir="ltr"><div><div>I think we could add an inner comm for external package. If the same comm is passed in again, we just retrieve the same communicator, instead of <span class="m_-7476549295757753627gmail-im">MPI_Comm_dup()</span>, for that external package (at least HYPRE team claimed this will be fine).   I did not see any issue with this idea so far. <br><br></div>I might be missing something here <br><br><br></div>Fande,<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 3, 2018 at 1:45 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Tue, 3 Apr 2018, Smith, Barry F. wrote:<br>
<br>
><br>
><br>
> > On Apr 3, 2018, at 11:59 AM, Balay, Satish <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > On Tue, 3 Apr 2018, Smith, Barry F. wrote:<br>
> ><br>
> >>   Note that PETSc does one MPI_Comm_dup() for each hypre matrix. Internally hypre does at least one MPI_Comm_create() per hypre boomerAMG solver. So even if PETSc does not do the MPI_Comm_dup() you will still be limited due to hypre's MPI_Comm_create.<br>
> >><br>
> >>    I will compose an email to hypre cc:ing everyone to get information from them.<br>
> ><br>
> > Actually I don't see any calls to MPI_Comm_dup() in hypre sources [there are stubs for it for non-mpi build]<br>
> ><br>
> > There was that call to MPI_Comm_create() in the stack trace [via hypre_BoomerAMGSetup]<br>
><br>
>    This is what I said. The MPI_Comm_create() is called for each solver and hence uses a slot for each solver.<br>
<br>
</span>Ops sorry - misread the text..<br>
<span class="m_-7476549295757753627HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br></div>