<div dir="ltr"><div>Mark,<br></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">The machine, compiler and MPI version should not matter.</blockquote><div><br></div><div>I might have missed something earlier in the thread, but parmetis has a dependency on the machine's glibc srand, and it can (and does) create different partitions with different srand versions. The same mesh on the same code on the same process count can and will give different partitions (possibly bad ones) on different machines.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 1:05 PM Mark Adams via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov">petsc-users@mcs.anl.gov</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 dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 17, 2019 at 12:53 PM Danyang Su <<a href="mailto:danyang.su@gmail.com" target="_blank">danyang.su@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 bgcolor="#FFFFFF">
    <p>Hi Mark,</p>
    <p>Thanks for your follow-up. <br>
    </p>
    <p>The unstructured grid code has been verified and there is no
      problem in the results. The convergence rate is also good. The 3D
      mesh is not good, it is based on the original stratum which I
      haven't refined, but good for initial test as it is relative small
      and the results obtained from this mesh still makes sense.</p>
    <p>The 2D meshes are just for testing purpose as I want to reproduce
      the partition problem on a cluster using PETSc3.11.3 and
      Intel2019. Unfortunately, I didn't find problem using this
      example. </p>
    <p>The code has no problem in using different PETSc versions (PETSc
      V3.4 to V3.11) </p></div></blockquote><div>OK, it is the same code. I thought I saw something about your code changing.</div><div><br></div><div>Just to be clear, v3.11 never gives you good partitions. It is not just a problem on this Intel cluster.</div><div><br></div><div>The machine, compiler and MPI version should not matter.</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 bgcolor="#FFFFFF"><p>and MPI distribution (MPICH, OpenMPI, IntelMPI),
      except for one simulation case (the mesh I attached) on a cluster
      with PETSc3.11.3 and Intel2019u4 due to the very different
      partition compared to PETSc3.9.3. Yet the simulation results are
      the same except for the efficiency problem because the strange
      partition results into much more communication (ghost nodes).</p>
    <p>I am still trying different compiler and mpi with PETSc3.11.3 on
      that cluster to trace the problem. Will get back to you guys when
      there is update.</p></div></blockquote><div><br></div><div>This is very strange. You might want to use 'git bisect'. You set a good and a bad SHA1 (we can give you this for 3.9 and 3.11 and the exact commands). The git will go to a version in the middle. You then reconfigure, remake, rebuild your code, run your test. Git will ask you, as I recall, if the version is good or bad. Once you get this workflow going it is not too bad, depending on how hard this loop is of course.</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 bgcolor="#FFFFFF">
    <p>Thanks,</p>
    <p>danyang</p>
  </div>

</blockquote></div></div>
</blockquote></div>