<div dir="ltr"><div dir="ltr">On Sun, Sep 15, 2019 at 6:59 PM Danyang Su <<a href="mailto:danyang.su@gmail.com">danyang.su@gmail.com</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"><div>Hi Matt,<br><br>Thanks for the quick reply. I have no change in the adjacency. The source code and the simulation input files are all the same. I also tried to use GNU compiler and mpich with petsc 3.11.3 and it works fine.<br><br>It looks like the problem is caused by the difference in configuration. However, the configuration is pretty the same as petsc 3.9.3 except the compiler and mpi used. I will contact scinet staff to check if they have any idea on this. <br></div></blockquote><div><br></div><div>Very very strange since the partition is handled completely by Metis, and does not use MPI.</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"><div>Thanks,<br><br>Danyang<br><br><div class="gmail_quote">On September 15, 2019 3:20:18 p.m. PDT, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 15, 2019 at 5:19 PM Danyang Su via petsc-users <<a href="mailto:petsc-users@mcs.anl.gov" target="_blank">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 bgcolor="#FFFFFF">
<p>Dear All,</p>
<p>I have a question regarding strange partition problem in PETSc
3.11 version. The problem does not exist on my local workstation.
However, on a cluster with different PETSc versions, the partition
seems quite different, as you can find in the figure below, which
is tested with 160 processors. The color means the processor owns
that subdomain. In this layered prism mesh, there are 40 layers
from bottom to top and each layer has around 20k nodes. The
natural order of nodes is also layered from bottom to top. <br>
</p>
<p>The left partition (PETSc 3.10 and earlier) looks good with
minimum number of ghost nodes while the right one (PETSc 3.11)
looks weired with huge number of ghost nodes. Looks like the right
one uses partition layer by layer. This problem exists on a a
cluster but not on my local workstation for the same PETSc version
(with different compiler and MPI). Other than the difference in
partition and efficiency, the simulation results are the same. <br>
</p>
<br>
<p><img alt="partition
difference" width="1054" height="633"></p>
<p>Below is PETSc configuration on three machine:</p>
<p>Local workstation (works fine): ./configure --with-cc=gcc
--with-cxx=g++ --with-fc=gfortran --download-mpich
--download-scalapack --download-parmetis --download-metis
--download-ptscotch --download-fblaslapack --download-hypre
--download-superlu_dist --download-hdf5=yes --download-ctetgen
--with-debugging=0 COPTFLAGS=-O3 CXXOPTFLAGS=-O3 FOPTFLAGS=-O3
--with-cxx-dialect=C++11</p>
<p>Cluster with PETSc 3.9.3 (works fine):
--prefix=/scinet/niagara/software/2018a/opt/intel-2018.2-intelmpi-2018.2/petsc/3.9.3
CC=mpicc CXX=mpicxx F77=mpif77 F90=mpif90 FC=mpifc
COPTFLAGS="-march=native -O2" CXXOPTFLAGS="-march=native -O2"
FOPTFLAGS="-march=native -O2" --download-chaco=1
--download-hypre=1 --download-metis=1 --download-ml=1
--download-mumps=1 --download-parmetis=1 --download-plapack=1
--download-prometheus=1 --download-ptscotch=1 --download-scotch=1
--download-sprng=1 --download-superlu=1 --download-superlu_dist=1
--download-triangle=1 --with-avx512-kernels=1
--with-blaslapack-dir=/scinet/niagara/intel/2018.2/compilers_and_libraries_2018.2.199/linux/mkl
--with-debugging=0 --with-hdf5=1
--with-mkl_pardiso-dir=/scinet/niagara/intel/2018.2/compilers_and_libraries_2018.2.199/linux/mkl
--with-scalapack=1
--with-scalapack-lib="[/scinet/niagara/intel/2018.2/compilers_and_libraries_2018.2.199/linux/mkl/lib/intel64/libmkl_scalapack_lp64.so,/scinet/niagara/intel/2018.2/compilers_and_libraries_2018.2.199/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so]"
--with-x=0</p>
<p>Cluster with PETSc 3.11.3 (looks weired):
--prefix=/scinet/niagara/software/2019b/opt/intel-2019u4-intelmpi-2019u4/petsc/3.11.3
CC=mpicc CXX=mpicxx F77=mpif77 F90=mpif90 FC=mpifc
COPTFLAGS="-march=native -O2" CXXOPTFLAGS="-march=native -O2"
FOPTFLAGS="-march=native -O2" --download-chaco=1 --download-hdf5=1
--download-hypre=1 --download-metis=1 --download-ml=1
--download-mumps=1 --download-parmetis=1 --download-plapack=1
--download-prometheus=1 --download-ptscotch=1 --download-scotch=1
--download-sprng=1 --download-superlu=1 --download-superlu_dist=1
--download-triangle=1 --with-avx512-kernels=1
--with-blaslapack-dir=/scinet/intel/2019u4/compilers_and_libraries_2019.4.243/linux/mkl
--with-cxx-dialect=C++11 --with-debugging=0
--with-mkl_pardiso-dir=/scinet/intel/2019u4/compilers_and_libraries_2019.4.243/linux/mkl
--with-scalapack=1
--with-scalapack-lib="[/scinet/intel/2019u4/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64/libmkl_scalapack_lp64.so,/scinet/intel/2019u4/compilers_and_libraries_2019.4.243/linux/mkl/lib/intel64/libmkl_blacs_intelmpi_lp64.so]"
--with-x=0</p>
<p>And the partition is used by default dmplex distribution.</p>
<p> !c distribute mesh over processes<br>
call
DMPlexDistribute(dmda_flow%da,stencil_width, &<br>
PETSC_NULL_SF, &<br>
PETSC_NULL_OBJECT, &<br>
distributedMesh,ierr)<br>
CHKERRQ(ierr)</p>
<p>Any idea on this strange problem? </p>
<p></p></div></blockquote><div>I just looked at the code. Your mesh should be partitioned by k-way partitioning using Metis since its on 1 proc for partitioning. This code</div><div>is the same for 3.9 and 3.11, and you get the same result on your machine. I cannot understand what might be happening on your cluster</div><div>(MPI plays no role). Is it possible that you changed the adjacency specification in that version?</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt </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<br>
</p>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_6005584983491990187gmail_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>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. Please excuse my brevity.</div></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>