<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div> Junchao,<div class=""><br class=""></div><div class=""> Thanks for checking this. </div><div class=""><br class=""></div><div class=""> Could you use PetscRegisterFinalize()? </div><div class=""><br class=""></div><div class=""> Barry</div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2021, at 10:46 PM, Junchao Zhang <<a href="mailto:junchao.zhang@gmail.com" class="">junchao.zhang@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""><br class=""></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 12, 2021 at 11:22 AM Barry Smith <<a href="mailto:bsmith@petsc.dev" target="_blank" class="">bsmith@petsc.dev</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">
User visible communicators generally do not have a keyval attached. Rather the keyval is attached to the inner communicator; because we don't want both PETSc and the user doing MPI operations on the same communicator (to prevent mixing up tags).<br class="">
<br class="">
I think PetscShmCommGet() is wrong. I think it should not call MPI_Comm_get_attr(globcomm,Petsc_Counter_keyval,&counter,&flg); but should call PetscCommDuplicate() and use that communicator to stash the pshmcomm; then you would not have the problem you are having.<br class=""></blockquote><div class="">Barry, I think it over and find the problem is: if I PetscCommDuplicate() the outer comm in PetscShmCommGet(), then I can not find a place to destroy the inner communicator (note usually petsc inner communciators are destroyed with petsc objects. Doing what you said breaks the rule)</div><div class=""><br class=""></div><div class="">PetscShmCommGet() was designed to help doing OpenMP multithreading on a communicator that some petsc objects live in. So requiring the input communicator to be petsc comm is not totally nonsense.<br class=""></div><div class=""><br class=""></div>I tried another approach: Don't check whether the input comm in PetscShmCommGet(globcomm,&pshmcomm) is an outer comm or an inner comm. We instead check its Petsc_ShmComm_keyval. If it does not have one, we just create one for it (along with a new shared memory communicator)</div><div class="gmail_quote">With that, one is able to call PetscShmCommGet(PETSC_COMM_WORLD, ...). The problem is we attached an attribute to PETSC_COMM_WORLD. It is deleted inside MPI_Finalize(). PETSc -malloc_dump complains of unfreed memory (since I used PetscMalloc inside PetscShmCommGet). I could<br class="">bypass PetscMalloc and directly use malloc() to avoid this situation. Is it worthy?<div class=""> <br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
<br class="">
Barry<br class="">
<br class="">
<br class="">
<br class="">
> On Aug 12, 2021, at 11:05 AM, Pierre Jolivet <<a href="mailto:pierre@joliv.et" target="_blank" class="">pierre@joliv.et</a>> wrote:<br class="">
> <br class="">
> Hello,<br class="">
> Is there a specific reason why PETSC_COMM_WORLD is not a PETSc communicator, i.e., has no Petsc_Counter_keyval attached?<br class="">
> ierr = PetscOmpCtrlCreate(PETSC_COMM_WORLD,nthreads,&ctrl);CHKERRQ(ierr);<br class="">
> yields<br class="">
> [0]PETSC ERROR: Bad MPI communicator supplied must be a PETSc communicator<br class="">
> [0]PETSC ERROR: #1 PetscShmCommGet() at src/sys/utils/mpishm.c:60<br class="">
> [0]PETSC ERROR: #2 PetscOmpCtrlCreate() at src/sys/utils/mpishm.c:340<br class="">
> <br class="">
> Thanks,<br class="">
> Pierre<br class="">
<br class="">
</blockquote></div></div>
</div></blockquote></div><br class=""></div></body></html>