<div dir="ltr"><div dir="ltr">On Wed, Jul 21, 2021 at 2:54 PM Eric Chamberland <<a href="mailto:Eric.Chamberland@giref.ulaval.ca">Eric.Chamberland@giref.ulaval.ca</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>
    <p>Hi Matthew,</p>
    <p>we did it with PetscSFCreateInverseSF !</p>
    <p>It is working well without overlap, so we can go forward with
      this and compute the overlap afterward with
      DMPlexDistributeOverlap.</p>
    <p></p></div></blockquote><div>That works. I think you can also do what you want with</div><div><br></div><div>  <a href="https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PetscSF/PetscSFComputeDegreeBegin.html">https://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/PetscSF/PetscSFComputeDegreeBegin.html</a></div><div><br></div><div>This is how I usually make the 2-sided information, unless I really need the inverse SF.</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><p>Thanks,</p>
    <p>Eric<br>
    </p>
    <p><br>
    </p>
    <div>On 2021-07-20 10:39 p.m., Eric
      Chamberland wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p><br>
      </p>
      <div>On 2021-07-14 6:42 p.m., Matthew
        Knepley wrote:<br>
      </div>
      <blockquote type="cite">
        
        <div dir="ltr">
          <div class="gmail_quote"><br>
            <div>Ah, there was a confusion of intent. GlobalToNatural()
              is for people that want data transformed back into the
              original</div>
            <div>order. I thought that was what you wanted. If you just
              want mesh points in the original order, we give you the</div>
            <div>transformation as part of the output of
              DMPlexDistribute(). The migrationSF that is output maps
              the original point to</div>
            <div>the distributed point. You run it backwards to get the
              original ordering.</div>
            <div><br>
            </div>
            <div>  Thanks,</div>
            <div><br>
            </div>
            <div>     Matt </div>
          </div>
        </div>
      </blockquote>
      <p>Hi,</p>
      <p>that seems to work better!  However, if I understand well the
        migrationSF is giving information on the originating process
        where the elements have been migrated from.</p>
      <p>Is there a PETSc way to either:</p>
      <p>1) send back the information to the originating process
        (somewhat "inverting" the migrationSF) ?  So I can retrieve the
        "partitioning array"  (just like the "part" parameter in
        ParMETIS_V3_PartMeshKway) on the sender process.<br>
      </p>
      <p>or<br>
      </p>
      <p>2) Have the pre-migrationSF: I mean I would like to extract the
        "where are the elements going to be sent?" (again like "part"
        parameter)</p>
      <p>If not, I can always build the communication myself...<br>
      </p>
      <p>Thanks,</p>
      <p>Eric</p>
      <p><br>
      </p>
      <p><br>
      </p>
      <p><br>
      </p>
    </blockquote>
    <pre cols="72">-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42</pre>
  </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>