<div dir="ltr">Hello, Randy,<div>  I further looked at the problem and believe it was due to overwhelming traffic. The code sometimes fails at MPI_Waitall. I printed out MPI error strings of bad MPI Statuses. One of them is like "MPID_nem_tcp_connpoll(1845): Communication error with rank 25: Connection reset by peer", which is a tcp error and has nothing to do with petsc.</div><div>  Further investigation shows in the case of 5120 ranks with 320 sub communicators, during VecScatterSetUp<span style="color:rgb(31,73,125);font-family:Verdana,sans-serif;font-size:13.3333px">, </span>each rank has around 640 isends/irecvs neighbors, and quite a few ranks has 1280 isends neighbors. I guess these overwhelming isends occasionally crashed the connection.</div><div>  The piece of code in VecScatterSetUp is to calculate the communication pattern. With index sets "having good locality", the calculate itself incurs less traffic. Here good locality means indices in an index set mostly point to local entries. However, the AOApplicationToPetsc() call in your code unnecessarily ruined the good petsc ordering. If we remove AOApplicationToPetsc() (the vecscatter result is still correct) , then each rank uniformly has around 320 isends/irecvs.</div><div>  So, test with this modification and see if it really works in your environment. If not applicable, we can provide options in petsc to carry out the communication in phases to avoid flooding the network (though it is better done by MPI). </div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div> Thanks.</div><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 17, 2020 at 10:47 AM Randall Mackie <<a href="mailto:rlmackie862@gmail.com">rlmackie862@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi Junchao,<div><br></div><div>Thank you for your efforts.</div><div>We tried petsc-3.13.0 but it made no difference.</div><div>We think now the issue are with sysctl parameters, and increasing those seemed to have cleared up the problem.</div><div>This also most likely explains how different clusters had different behaviors with our test code.</div><div><br></div><div>We are now running our code and will report back once we are sure that there are no further issues.</div><div><br></div><div>Thanks again for your help.</div><div><br></div><div>Randy M.</div><div></div><div><br><blockquote type="cite"><div>On Apr 17, 2020, at 8:09 AM, Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 11:13 PM Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Randy,<div>  I reproduced your error with petsc-3.12.4 and 5120 mpi ranks. I also found the error went away with petsc-3.13.  However, I have not figured out what is the bug and which commit fixed it :).</div><div>  So at your side, it is better to use the latest petsc.<br clear="all"></div></div></blockquote><div>I want to add that even with petsc-3.12.4 the error is random. I was only able to reproduce the error once, so I can not claim petsc-3.13 actually fixed it (or, the bug is really in petsc).</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"><div dir="ltr"><div><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 16, 2020 at 9:06 PM Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Randy,<div>  Up to now I could not reproduce your error, even with the biggest mpirun -n 5120 ./test -nsubs 320 -nx 100 -ny 100 -nz 100</div><div>  While I continue doing test, you can try other options. It looks you want to duplicate a vector to subcomms. I don't think you need the two lines:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">call AOApplicationToPetsc(aoParent,nis,ind1,ierr)<br>call AOApplicationToPetsc(aoSub,nis,ind2,ierr)</blockquote><div style="line-height:21px"><div> In addition, you can use simpler and more memory-efficient index sets. There is a petsc example for this task, see case 3 in <a href="https://gitlab.com/petsc/petsc/-/blob/master/src/vec/vscat/tests/ex9.c" target="_blank">https://gitlab.com/petsc/petsc/-/blob/master/src/vec/vscat/tests/ex9.c</a></div></div><div> BTW, it is good to use petsc master so we are on the same page.</div><div><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020 at 10:28 AM Randall Mackie <<a href="mailto:rlmackie862@gmail.com" target="_blank">rlmackie862@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Junchao,<div><br></div><div>So I was able to create a small test code that duplicates the issue we have been having, and it is attached to this email in a zip file.</div><div>Included is the test.F90 code, the commands to duplicate crash and to duplicate a successful run, output errors, and our petsc configuration.</div><div><br></div><div>Our findings to date include:</div><div><br></div><div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif">The error is reproducible in a very short time with this script</div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:11pt">It is related to nproc*nsubs and (although to a less extent) to DM grid size</span></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><u></u><u></u></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif">It happens regardless of MPI implementation (mpich, intel mpi 2018, 2019, openmpi) or compiler (gfortran/gcc , intel 2018)<u></u><u></u></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif">No effect changing vecscatter_type to mpi1 or mpi3. Mpi1 seems to slightly increase the limit, but still fails on the full machine set.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif">Nothing looks interesting on valgrind</div><div><br></div><div>Our initial tests were carried out on an Azure cluster, but we also tested on our smaller cluster, and we found the following:</div><div><br></div><div><div style="margin:0in 0in 0.0001pt;font-size:11pt">Works:<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt">$PETSC_DIR/lib/petsc/bin/petscmpiexec -n 1280 -hostfile hostfile ./test -nsubs 80 -nx 100 -ny 100 -nz 100<span style="background-color:black"><u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt"><span style="color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt"><span style="color:rgb(31,73,125)">Crashes (this works on Azure)<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt">$PETSC_DIR/lib/petsc/bin/petscmpiexec -n 2560 -hostfile hostfile ./test -nsubs 80 -nx 100 -ny 100 -nz 100</div><div style="margin:0in 0in 0.0001pt;font-size:11pt"><br></div><div style="margin:0in 0in 0.0001pt;font-size:11pt">So it looks like it may also be related to the physical number of nodes as well.</div><div style="margin:0in 0in 0.0001pt;font-size:11pt"><br></div><div style="margin:0in 0in 0.0001pt;font-size:11pt">In any case, even with 2560 processes on 192 cores the memory does not go above 3.5 Gbyes so you don’t need a huge cluster to test.</div></div><div><br></div><div>Thanks,</div></div><div><br></div><div>Randy M.</div><div><br></div><div></div></div><div><div></div><div><br></div><div><br><blockquote type="cite"><div>On Apr 14, 2020, at 12:23 PM, Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:</div><br><div><div dir="ltr">There is an MPI_Allreduce in PetscGatherNumberOfMessages, that is why I doubted it was the problem. Even if users configure petsc with 64-bit indices, we use PetscMPIInt in MPI calls. So it is not a problem.<div>Try -vecscatter_type mpi1 to restore to the original VecScatter implementation. If the problem still remains, could you provide a test example for me to debug?</div><div><div><br></div><div><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 14, 2020 at 12:13 PM Randall Mackie <<a href="mailto:rlmackie862@gmail.com" target="_blank">rlmackie862@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Hi Junchao,<div><br></div><div>We have tried your two suggestions but the problem remains.</div><div>And the problem seems to be on the MPI_Isend line 117 in PetscGatherMessageLengths and not MPI_AllReduce.</div><div><br></div><div>We have now tried Intel MPI, Mpich, and OpenMPI, and so are thinking the problem must be elsewhere and not MPI.</div><div><br></div><div>Give that this is a 64 bit indices build of PETSc, is there some possible incompatibility between PETSc and MPI calls?</div><div><br></div><div>We are open to any other possible suggestions to try as other than valgrind on thousands of processes we seem to have run out of ideas.</div><div><br></div><div>Thanks, Randy M.</div><div><br></div><div><div><blockquote type="cite"><div>On Apr 13, 2020, at 8:54 AM, Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 10:53 AM Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" target="_blank">junchao.zhang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Randy,</div><div>   Someone reported similar problem before. It turned out an Intel MPI MPI_Allreduce bug.  A workaround is setting the environment variable I_MPI_ADJUST_ALLREDUCE=1.arr</div></div></blockquote><div> Correct:  I_MPI_ADJUST_ALLREDUCE=1</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>   But you mentioned mpich also had the error. So maybe the problem is not the same. So let's try the workaround first. If it doesn't work, add another petsc option -build_twosided allreduce, which is a workaround for Intel MPI_Ibarrier bugs we met.</div>   Thanks.<br clear="all"><div><div dir="ltr"><div dir="ltr">--Junchao Zhang</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 13, 2020 at 10:38 AM Randall Mackie <<a href="mailto:rlmackie862@gmail.com" target="_blank">rlmackie862@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Dear PETSc users,<div><br></div><div>We are trying to understand an issue that has come up in running our code on a large cloud cluster with a large number of processes and subcomms.</div><div>This is code that we use daily on multiple clusters without problems, and that runs valgrind clean for small test problems.</div><div><br></div><div>The run generates the following messages, but doesn’t crash, just seems to hang with all processes continuing to show activity:</div><div><br></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">[492]PETSC ERROR: #1 PetscGatherMessageLengths() line 117 in /mnt/home/cgg/PETSc/petsc-3.12.4/src/sys/utils/mpimesg.c<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">[492]PETSC ERROR: #2 VecScatterSetUp_SF() line 658 in /mnt/home/cgg/PETSc/petsc-3.12.4/src/vec/vscat/impls/sf/vscatsf.c<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="font-size:10pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">[492]PETSC ERROR: #3 VecScatterSetUp() line 209 in /mnt/home/cgg/PETSc/petsc-3.12.4/src/vec/vscat/interface/vscatfce.c<u></u><u></u></span></div><div><span style="color:rgb(31,73,125);font-family:Verdana,sans-serif;font-size:10pt">[492]PETSC ERROR: #4 VecScatterCreate() line 282 in /mnt/home/cgg/PETSc/petsc-3.12.4/src/vec/vscat/interface/vscreate.c</span></div><div><br></div><div><br></div><div>Looking at line 117 in PetscGatherMessageLengths we find the offending statement is the MPI_Isend:</div><div><br></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="color:rgb(31,73,125)"> </span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">  /* Post the Isends with the message length-info */</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">  for (i=0,j=0; i<size; ++i) {</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">    if (ilengths[i]) {</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">      ierr = MPI_Isend((void*)(ilengths+i),1,MPI_INT,i,tag,comm,s_waits+j);CHKERRQ(ierr);</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">      j++;</span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:"Courier New";color:rgb(31,73,125)">    }</span><u></u><u></u></div><div><span style="color:rgb(31,73,125);font-family:"Courier New";font-size:11pt">  }</span> </div><div><br></div><div>We have tried this with Intel MPI 2018, 2019, and mpich, all giving the same problem.</div><div><br></div><div>We suspect there is some limit being set on this cloud cluster on the number of file connections or something, but we don’t know.</div><div><br></div><div>Anyone have any ideas? We are sort of grasping for straws at this point.</div><div><br></div><div>Thanks, Randy M.</div></div></blockquote></div>
</blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote></div>
</div></blockquote></div><br></div></blockquote></div>
</blockquote></div>
</blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div>