<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 dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><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">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>