<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <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>Thanks,</p>
    <p>Eric<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 2021-07-20 10:39 p.m., Eric
      Chamberland wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:7b11445b-4d50-20d4-7c25-6cb2eab043b6@giref.ulaval.ca">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <p><br>
      </p>
      <div class="moz-cite-prefix">On 2021-07-14 6:42 p.m., Matthew
        Knepley wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CAMYG4GkfZyvrc+jNOhLbqqG=qyb6v7ViY2_4mOyaqT_=U2FTpg@mail.gmail.com">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <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 class="moz-signature" cols="72">-- 
Eric Chamberland, ing., M. Ing
Professionnel de recherche
GIREF/Université Laval
(418) 656-2131 poste 41 22 42</pre>
  </body>
</html>