<div dir="ltr">I like the idea that Hypre (as a package) would get _one_ comm (for all the solvers/matrices created) that was duped from the one given to PETSc in Vec/MatCreate().<div><br></div><div>Seems like the tricky part would be figuring out _which_ comm that is based on the incoming comm. For instance - we would definitely have the case where we are doing a Hypre solve on effectively COMM_WORLD… and then many Hypre solves on sub-communicators (and even Hypre solves on sub-communicators of those sub-communicators). The system for getting “the” Hypre Comm would have to match up the incoming Comm in the Vec/MatCreate() call and find the correct Hypre comm to use.</div><div><br></div><div>Derek</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Apr 3, 2018 at 7:46 AM Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fande claimed 49a781f5cee36db85e8d5b951eec29f10ac13593 made a difference. [so assuming same hypre version was used before and after this commit - for this bisection]<br>
<br>
So the extra MPI_Comm_dup() calls due to MATHYPRE must be pushing the total communicators over the limit.<br>
<br>
And wrt debugging - perhaps we need to check MPI_Comm_free() aswell? Presumably freed communicators can get reused so we have to look for outstanding/unfreed communicators?<br>
<br>
Per message below - MPICH[?] provides a max of 2048 communicators. And there is some discussion of this issue at: <a href="https://lists.mpich.org/pipermail/discuss/2012-December/000148.html" rel="noreferrer" target="_blank">https://lists.mpich.org/pipermail/discuss/2012-December/000148.html</a><br>
<br>
And wrt 'sharing' - I was thining in terms of: Can one use MPI_COMM_WORLD with all hypre objects we create? If so - we could somehow attach one more inner-comm - that could be obtained and reused with multiple hypre objects [that got created off the same petsc_comm?]<br>
<br>
Satish<br>
<br>
On Tue, 3 Apr 2018, Smith, Barry F. wrote:<br>
<br>
><br>
> Each external package definitely needs its own duplicated communicator; cannot share between packages.<br>
><br>
> The only problem with the dups below is if they are in a loop and get called many times.<br>
><br>
> To debug the hypre/duplication issue in MOOSE I would run in the debugger with a break point in MPI_Comm_dup() and see<br>
> who keeps calling it an unreasonable amount of times. (My guess is this is a new "feature" in hypre that they will need to fix but only debugging will tell)<br>
><br>
> Barry<br>
><br>
><br>
> > On Apr 2, 2018, at 7:44 PM, Balay, Satish <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> ><br>
> > We do a MPI_Comm_dup() for objects related to externalpackages.<br>
> ><br>
> > Looks like we added a new mat type MATHYPRE - in 3.8 that PCHYPRE is<br>
> > using. Previously there was one MPI_Comm_dup() PCHYPRE - now I think<br>
> > is one more for MATHYPRE - so more calls to MPI_Comm_dup in 3.8 vs 3.7<br>
> ><br>
> > src/dm/impls/da/hypre/mhyp.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)B),&(ex->hcomm));CHKERRQ(ierr);<br>
> > src/dm/impls/da/hypre/mhyp.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)B),&(ex->hcomm));CHKERRQ(ierr);<br>
> > src/dm/impls/swarm/data_ex.c: ierr = MPI_Comm_dup(comm,&d->comm);CHKERRQ(ierr);<br>
> > src/ksp/pc/impls/hypre/hypre.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)pc),&(jac->comm_hypre));CHKERRQ(ierr);<br>
> > src/ksp/pc/impls/hypre/hypre.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)pc),&(ex->hcomm));CHKERRQ(ierr);<br>
> > src/ksp/pc/impls/hypre/hypre.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)pc),&(ex->hcomm));CHKERRQ(ierr);<br>
> > src/ksp/pc/impls/spai/ispai.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)pc),&(ispai->comm_spai));CHKERRQ(ierr);<br>
> > src/mat/examples/tests/ex152.c: ierr = MPI_Comm_dup(MPI_COMM_WORLD, &comm);CHKERRQ(ierr);<br>
> > src/mat/impls/aij/mpi/mkl_cpardiso/mkl_cpardiso.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)A),&(mat_mkl_cpardiso->comm_mkl_cpardiso));CHKERRQ(ierr);<br>
> > src/mat/impls/aij/mpi/mumps/mumps.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)A),&(mumps->comm_mumps));CHKERRQ(ierr);<br>
> > src/mat/impls/aij/mpi/pastix/pastix.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)A),&(lu->pastix_comm));CHKERRQ(ierr);<br>
> > src/mat/impls/aij/mpi/superlu_dist/superlu_dist.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)A),&(lu->comm_superlu));CHKERRQ(ierr);<br>
> > src/mat/impls/hypre/mhypre.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)B),&hB->comm);CHKERRQ(ierr);<br>
> > src/mat/partition/impls/pmetis/pmetis.c: ierr = MPI_Comm_dup(pcomm,&comm);CHKERRQ(ierr);<br>
> > src/sys/mpiuni/mpi.c: MPI_COMM_SELF, MPI_COMM_WORLD, and a MPI_Comm_dup() of each of these (duplicates of duplicates return the same communictor)<br>
> > src/sys/mpiuni/mpi.c:int MPI_Comm_dup(MPI_Comm comm,MPI_Comm *out)<br>
> > src/sys/objects/pinit.c: ierr = MPI_Comm_dup(MPI_COMM_WORLD,&local_comm);CHKERRQ(ierr);<br>
> > src/sys/objects/pinit.c: ierr = MPI_Comm_dup(MPI_COMM_WORLD,&local_comm);CHKERRQ(ierr);<br>
> > src/sys/objects/tagm.c: ierr = MPI_Comm_dup(comm_in,comm_out);CHKERRQ(ierr);<br>
> > src/sys/utils/mpiu.c: ierr = MPI_Comm_dup(comm,&local_comm);CHKERRQ(ierr);<br>
> > src/ts/impls/implicit/sundials/sundials.c: ierr = MPI_Comm_dup(PetscObjectComm((PetscObject)ts),&(cvode->comm_sundials));CHKERRQ(ierr);<br>
> ><br>
> > Perhaps we need a PetscCommDuplicateExternalPkg() to somehow avoid these MPI_Comm_dup() calls?<br>
> ><br>
> > Satish<br>
> ><br>
> > On Tue, 3 Apr 2018, Smith, Barry F. wrote:<br>
> ><br>
> >><br>
> >> Are we sure this is a PETSc comm issue and not a hypre comm duplication issue<br>
> >><br>
> >> frame #6: 0x00000001061345d9 libpetsc.3.07.dylib`hypre_GenerateSubComm(comm=-1006627852, participate=<unavailable>, new_comm_ptr=<unavailable>) + 409 at gen_redcs_mat.c:531 [opt]<br>
> >><br>
> >> Looks like hypre is needed to generate subcomms, perhaps it generates too many?<br>
> >><br>
> >> Barry<br>
> >><br>
> >><br>
> >>> On Apr 2, 2018, at 7:07 PM, Derek Gaston <<a href="mailto:friedmud@gmail.com" target="_blank">friedmud@gmail.com</a>> wrote:<br>
> >>><br>
> >>> I’m working with Fande on this and I would like to add a bit more. There are many circumstances where we aren’t working on COMM_WORLD at all (e.g. working on a sub-communicator) but PETSc was initialized using MPI_COMM_WORLD (think multi-level solves)… and we need to create arbitrarily many PETSc vecs/mats/solvers/preconditioners and solve. We definitely can’t rely on using PETSC_COMM_WORLD to avoid triggering duplication.<br>
> >>><br>
> >>> Can you explain why PETSc needs to duplicate the communicator so much?<br>
> >>><br>
> >>> Thanks for your help in tracking this down!<br>
> >>><br>
> >>> Derek<br>
> >>><br>
> >>> On Mon, Apr 2, 2018 at 5:44 PM Kong, Fande <<a href="mailto:fande.kong@inl.gov" target="_blank">fande.kong@inl.gov</a>> wrote:<br>
> >>> Why we do not use user-level MPI communicators directly? What are potential risks here?<br>
> >>><br>
> >>><br>
> >>> Fande,<br>
> >>><br>
> >>> On Mon, Apr 2, 2018 at 5:08 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> >>> PETSC_COMM_WORLD [via PetscCommDuplicate()] attempts to minimize calls to MPI_Comm_dup() - thus potentially avoiding such errors<br>
> >>><br>
> >>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mcs.anl.gov_petsc_petsc-2Dcurrent_docs_manualpages_Sys_PetscCommDuplicate.html&d=DwIBAg&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=jgv7gpZ3K52d_FWMgkK9yEScbLA7pkrWydFuJnYflsU&s=_zpWRcyk3kHuEHoq02NDqYExnXIohXpNnjyabYnnDjU&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__www.mcs.anl.gov_petsc_petsc-2Dcurrent_docs_manualpages_Sys_PetscCommDuplicate.html&d=DwIBAg&c=54IZrppPQZKX9mLzcGdPfFD1hxrcB__aEkJFOKJFd00&r=DUUt3SRGI0_JgtNaS3udV68GRkgV4ts7XKfj2opmiCY&m=jgv7gpZ3K52d_FWMgkK9yEScbLA7pkrWydFuJnYflsU&s=_zpWRcyk3kHuEHoq02NDqYExnXIohXpNnjyabYnnDjU&e=</a><br>
> >>><br>
> >>><br>
> >>> Satish<br>
> >>><br>
> >>> On Mon, 2 Apr 2018, Kong, Fande wrote:<br>
> >>><br>
> >>>> On Mon, Apr 2, 2018 at 4:23 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>> wrote:<br>
> >>>><br>
> >>>>> Does this 'standard test' use MPI_COMM_WORLD' to crate PETSc objects?<br>
> >>>>><br>
> >>>>> If so - you could try changing to PETSC_COMM_WORLD<br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>>> I do not think we are using PETSC_COMM_WORLD when creating PETSc objects.<br>
> >>>> Why we can not use MPI_COMM_WORLD?<br>
> >>>><br>
> >>>><br>
> >>>> Fande,<br>
> >>>><br>
> >>>><br>
> >>>>><br>
> >>>>> Satish<br>
> >>>>><br>
> >>>>><br>
> >>>>> On Mon, 2 Apr 2018, Kong, Fande wrote:<br>
> >>>>><br>
> >>>>>> Hi All,<br>
> >>>>>><br>
> >>>>>> I am trying to upgrade PETSc from 3.7.6 to 3.8.3 for MOOSE and its<br>
> >>>>>> applications. I have a error message for a standard test:<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> *preconditioners/pbp.lots_of_variables: MPI had an<br>
> >>>>>> errorpreconditioners/pbp.lots_of_variables:<br>
> >>>>>> ------------------------------------------------<br>
> >>>>> preconditioners/pbp.lots_of_variables:<br>
> >>>>>> Other MPI error, error stack:preconditioners/pbp.lots_of_variables:<br>
> >>>>>> PMPI_Comm_dup(177)..................: MPI_Comm_dup(comm=0x84000001,<br>
> >>>>>> new_comm=0x97d1068) failedpreconditioners/pbp.lots_of_variables:<br>
> >>>>>> PMPI_Comm_dup(162)..................:<br>
> >>>>>> preconditioners/pbp.lots_of_variables:<br>
> >>>>>> MPIR_Comm_dup_impl(57)..............:<br>
> >>>>>> preconditioners/pbp.lots_of_variables:<br>
> >>>>>> MPIR_Comm_copy(739).................:<br>
> >>>>>> preconditioners/pbp.lots_of_variables:<br>
> >>>>>> MPIR_Get_contextid_sparse_group(614): Too many communicators (0/2048<br>
> >>>>> free<br>
> >>>>>> on this process; ignore_id=0)*<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> I did "git bisect', and the following commit introduces this issue:<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> *commit 49a781f5cee36db85e8d5b951eec29f10ac13593Author: Stefano Zampini<br>
> >>>>>> <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a> <<a href="mailto:stefano.zampini@gmail.com" target="_blank">stefano.zampini@gmail.com</a>>>Date: Sat Nov 5<br>
> >>>>>> 20:15:19 2016 +0300 PCHYPRE: use internal Mat of type MatHYPRE<br>
> >>>>>> hpmat already stores two HYPRE vectors*<br>
> >>>>>><br>
> >>>>>> Before I debug line-by-line, anyone has a clue on this?<br>
> >>>>>><br>
> >>>>>><br>
> >>>>>> Fande,<br>
> >>>>>><br>
> >>>>><br>
> >>>>><br>
> >>>><br>
> >>><br>
> >><br>
><br>
><br>
</blockquote></div>