<div dir="ltr"><div dir="ltr"><br><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 11:21 PM Barry Smith <<a href="mailto:bsmith@petsc.dev">bsmith@petsc.dev</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"><br>
   Whenever PETSc is handed a communicator it looks for an attribute inside of the communicator that contains the "PETSc" version of that communicator. If it does not find the attribute it adds an attribute with a new communicator in, if it does find one it increases its reference count by one. The routine it uses to perform this is PetscCommDuplicate(). We do it this was so that PETSc communication will never potentially interfere with the users use of their communicators. PetscCommDestroy() decreases the reference count of the inner communicator by one. So, for example, if you use "comm" to create two PETSc objects, PETSc will create an attribute on "comm" with a new communicator, when both objects are destroy then PetscCommDestroy() will have been called twice and the inner (PETSc) communicator will be destroyed. <br>
<br>
  If someone did <br>
<br>
      Use MPI to create a new communicator<br>
      VecCreate(comm,...)<br>
      Use MPI to destroy the new communicator<br>
      ....<br>
      VecDestroy()<br></blockquote>The code above will work correctly.  In 'Use MPI to destroy the new communicator',  MPI finds out <i>comm</i> has an attribute Petsc_InnerComm_keyval, so it invokes a petsc function Petsc_InnerComm_Attr_Delete_Fn (which was given to MPI at PetscInitialize).</div><div class="gmail_quote">In Petsc_InnerComm_Attr_Delete_Fn, it cuts the link between <i>comm</i> and its inner petsc comm (which is still used by vec in this example). The inner petsc comm is still valid and accessible via PetscObjectComm(). It will be destroyed when its reference count (managed by petsc) reaches zero (probably in VecDestroy).</div><div class="gmail_quote"><br><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am not sure what will happen since PETSc keeps a reference to the outer communicator from its own inner communicator. And destroying the user communicator will cause an attempt to destroy the attribute containing the inner PETSc communicator.  I had always just assumed the user would not be deleting any MPI communicators they made and pass to PETSc until they were done with PETSc. It may work correctly but may not.<br>
<br>
The reality is very few MPI codes have complicated life cycles for MPI communicators. <br>
<br>
Barry<br>
<br>
<br>
> On Jul 8, 2021, at 10:17 PM, Kozdon, Jeremy (CIV) <<a href="mailto:jekozdon@nps.edu" target="_blank">jekozdon@nps.edu</a>> wrote:<br>
> <br>
> Sorry if this is clearly stated somewhere in the docs, I'm still getting familiar with the petsc codebase and was also unable to find the answer searching (nor could I determine where this would be done in the source).<br>
> <br>
> Does petsc duplicate MPI communicators? Or does the users program need to make sure that the communicator remains valid for the life of a petsc object?<br>
> <br>
> The attached little test code seems to suggest that there is some duplication of MPI communicators behind the scenes.<br>
> <br>
> This came up when working on Julia wrappers for petsc. (Julia has a garbage collector so we need to make sure that references are properly kept if needed.)<br>
> <br>
> <try.c><br>
<br>
</blockquote></div></div>