<div dir="ltr"><div dir="ltr">On Thu, Aug 19, 2021 at 2:08 PM Feimi Yu <<a href="mailto:yuf2@rpi.edu">yuf2@rpi.edu</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Jed,<br>
<br>
In my case, I only have 2 hypre preconditioners at the same time, and <br>
they do not solve simultaneously, so it might not be case 1.<br>
<br>
I checked the stack for all the calls of MPI_Comm_dup/MPI_Comm_free on <br>
my own machine (with OpenMPI), all the communicators are freed from my <br>
observation. I could not test it with Spectrum MPI on the clusters <br>
immediately because all the dependencies were built in release mode. <br>
However, as I mentioned, I haven't had this problem with OpenMPI before, <br>
so I'm not sure if this is really an MPI implementation problem, or just <br>
because Spectrum MPI has less limit for the number of communicators, <br>
and/or this also depends on how many MPI ranks are used, as only 2 out <br>
of 40 ranks reported the error.<br>
<br>
As a workaround, I replaced the MPI_Comm_dup() at <br>
petsc/src/mat/impls/hypre/mhypre.c:2120 with a copy assignment, and also <br>
removed the MPI_Comm_free() in the hypre destroyer. My code runs fine <br>
with Spectrum MPI now, but I don't think this is a long-term solution.<br></blockquote><div><br></div><div>If that runs, then it is definitely an MPI implementation problem.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks!<br>
<br>
Feimi<br>
<br>
On 8/19/21 9:01 AM, Jed Brown wrote:<br>
> Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> writes:<br>
><br>
>> Hi, Feimi,<br>
>>    I need to consult Jed (cc'ed).<br>
>>    Jed, is this an example of<br>
>> <a href="https://lists.mcs.anl.gov/mailman/htdig/petsc-dev/2018-April/thread.html#22663" rel="noreferrer" target="_blank">https://lists.mcs.anl.gov/mailman/htdig/petsc-dev/2018-April/thread.html#22663</a>?<br>
>> If Feimi really can not free matrices, then we just need to attach a<br>
>> hypre-comm to a petsc inner comm, and pass that to hypre.<br>
> Are there a bunch of solves as in that case?<br>
><br>
> My understanding is that one should be able to MPI_Comm_dup/MPI_Comm_free as many times as you like, but the implementation has limits on how many communicators can co-exist at any one time. The many-at-once is what we encountered in that 2018 thread.<br>
><br>
> One way to check would be to use a debugger or tracer to examine the stack every time (P)MPI_Comm_dup and (P)MPI_Comm_free are called.<br>
><br>
> case 1: we'll find lots of dups without frees (until the end) because the user really wants lots of these existing at the same time.<br>
><br>
> case 2: dups are unfreed because of reference counting issue/inessential references<br>
><br>
><br>
> In case 1, I think the solution is as outlined in the thread, PETSc can create an inner-comm for Hypre. I think I'd prefer to attach it to the outer comm instead of the PETSc inner comm, but perhaps a case could be made either way.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><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.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>