<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 18, 2013 at 9:47 AM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">On Mon, Nov 18, 2013 at 3:24 AM, Michael Lange <span dir="ltr"><<a href="mailto:michael.lange@imperial.ac.uk" target="_blank">michael.lange@imperial.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div>Hi Matt,<br>
      <br>
      I think there is a misunderstanding here. I am referring to the
      case where DMPlexDistribute() is run with overlap=1 (which is not
      the case in SNES ex12) and vertices in the overlap/halo region are
      assigned to the wrong rank. This can lead to a case where a proc
      may own a vertex that is not in its original (non-overlapping)
      partition, although the attached cell is not owned and will be
      marked as "ghost" by DMPlexConstructGhostCells().<br></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>Your fix is now merged to next:</div><div><br></div><div>   <a href="https://bitbucket.org/petsc/petsc/branch/knepley/fix-plex-partition-overlap">https://bitbucket.org/petsc/petsc/branch/knepley/fix-plex-partition-overlap</a></div>
<div><br></div><div>    Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div>
      To illustrate this, I have attached an example consisting of a
      unit square with 3 faces in each dimension and a section with only
      vertex dofs. If run with two ranks, rank 1 will own all its
      vertices (13 roots), whereas rank 0 only owns vertices not in the
      overlap/halo of rank 1 (3 roots). My understanding is that, since
      the original partition splits the square along its diagonal, the
      vertex distribution should be 10 to 6 with the 4 diagonal vertices
      assigned to rank 1 and all other vertices assigned according to
      the original partition. Is this correct, or am I missing something
      here?<br></div></div></blockquote><div><br></div></div><div>I have simplified the example so that I can easily do things in my head. Now we just have 2 faces per side. Here is the run with overlap = 0:</div><div><br>
</div>
<div><div>next *$:/PETSc3/petsc/petsc-dev$ /PETSc3/petsc/petsc-dev/arch-c-exodus-next/bin/mpiexec -host localhost -n 2 /PETSc3/petsc/petsc-dev/arch-c-exodus-next/lib/plex_overlap-obj/plex_overlap -dm_view -overlap 0</div>

<div>Parallel Mesh in 2 dimensions:</div><div>  0-cells: 6 6</div><div>  1-cells: 9 9</div><div>  2-cells: 4 4</div><div>Labels:</div><div>  depth: 3 strata of sizes (6, 9, 4)</div><div>  exterior_facets: 1 strata of sizes (4)</div>

<div>  marker: 2 strata of sizes (9, 3)</div><div class="im"><div>PetscSF Object: 2 MPI processes</div><div>  type: basic</div><div>    sort=rank-order</div><div>  [0] Number of roots=19, leaves=5, remote ranks=1</div><div>
  [0] 4 <- (1,6)</div>
<div>  [0] 5 <- (1,8)</div><div>  [0] 7 <- (1,9)</div><div>  [0] 10 <- (1,13)</div><div>  [0] 11 <- (1,17)</div><div>  [1] Number of roots=19, leaves=0, remote ranks=0</div></div></div><div><br></div><div>Each partition gets 4 cells and 6 vertices since it is split along the diagonal. The overlap</div>

<div>region contains the 3 vertices and 2 faces that lie on the diagonal, and they are all owned by proc 1.</div><div>Now if we run with an overlap of 1:</div><div><br></div><div><div>next *$:/PETSc3/petsc/petsc-dev$ /PETSc3/petsc/petsc-dev/arch-c-exodus-next/bin/mpiexec -host localhost -n 2 /PETSc3/petsc/petsc-dev/arch-c-exodus-next/lib/plex_overlap-obj/plex_overlap -dm_view -overlap 1</div>

<div>Parallel Mesh in 2 dimensions:<br></div><div>  0-cells: 8 8</div><div>  1-cells: 13 13</div><div>  2-cells: 6 6</div><div>Labels:</div><div>  depth: 3 strata of sizes (8, 13, 6)</div><div>  exterior_facets: 1 strata of sizes (6)</div>

<div>  marker: 2 strata of sizes (13, 5)</div><div class="im"><div>PetscSF Object: 2 MPI processes</div><div>  type: basic</div><div>    sort=rank-order</div></div><div>  [0] Number of roots=27, leaves=19, remote ranks=1</div>
<div>  [0] 0 <- (1,1)</div>
<div>  [0] 2 <- (1,4)</div><div>  [0] 6 <- (1,7)</div><div>  [0] 7 <- (1,8)</div><div>  [0] 8 <- (1,9)</div><div>  [0] 9 <- (1,10)</div><div>  [0] 10 <- (1,11)</div><div>  [0] 11 <- (1,12)</div><div>
  [0] 12 <- (1,13)</div>
<div>  [0] 14 <- (1,17)</div><div>  [0] 15 <- (1,18)</div><div>  [0] 16 <- (1,19)</div><div>  [0] 17 <- (1,20)</div><div>  [0] 18 <- (1,21)</div><div>  [0] 19 <- (1,22)</div><div>  [0] 20 <- (1,23)</div>

<div>  [0] 21 <- (1,24)</div><div>  [0] 25 <- (1,25)</div><div>  [0] 26 <- (1,26)</div><div>  [1] Number of roots=27, leaves=2, remote ranks=1</div><div>  [1] 3 <- (0,1)</div><div>  [1] 5 <- (0,5)</div></div>

<div><br></div><div>Each process gets 2 more cells (those who faces lie on the diagonal), 2 more vertices and 4 more edges. This is correct. The</div><div>two overlap cells are ghost for proc 1, but the 4 edges and 2 vertices are owned. So you are correct, I need to mark all those</div>

<div>overlap points as "unownable" by the original process.</div><div><br></div><div>  Thanks for finding this,</div><div><br></div><div>      Matt</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div text="#000000" bgcolor="#FFFFFF"><div>
      Many thanks for all your help<br>
      Michael<br>
      <br>
      On 16/11/13 13:54, Matthew Knepley wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><div>On Sat, Nov 16, 2013 at 7:22 AM,
            Michael Lange <span dir="ltr"><<a href="mailto:michael.lange@imperial.ac.uk" target="_blank">michael.lange@imperial.ac.uk</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
              <br>
              I notice that, when creating the point SF for the parallel
              partition in DMPlexDistribute, cells are assigned to procs
              according to the original partition but vertices aren't.
              Was this done by design or is this a bug?<br>
            </blockquote>
            <div><br>
            </div>
            </div><div>If this were true, there would be no communication for
              the P1 test of SNES ex12. Here is running it with</div>
            <div>-interpolate 1 and -dm_view ::ascii_info_detail</div>
            <div><br>
            </div>
            <div>
              <div>PetscSF Object: 2 MPI processes</div>
              <div>  type: basic</div>
              <div>    sort=rank-order</div>
              <div>  [0] Number of roots=19, leaves=5, remote ranks=1</div>
              <div>  [0] 4 <- (1,6)</div>
              <div>  [0] 5 <- (1,8)</div>
              <div>
                  [0] 7 <- (1,9)</div>
              <div>  [0] 10 <- (1,13)</div>
              <div>  [0] 11 <- (1,17)</div>
              <div>  [1] Number of roots=19, leaves=0, remote ranks=0</div>
              <div>  [0] Roots referenced by my leaves, by rank</div>
              <div>  [0] 1: 5 edges</div>
              <div>  [0]    4 <- 6</div>
              <div>  [0]    5 <- 8</div>
              <div>  [0]    7 <- 9</div>
              <div>  [0]    10 <- 13</div>
              <div>  [0]    11 <- 17</div>
              <div>  [1] Roots referenced by my leaves, by rank</div>
            </div>
            <div><br>
            </div>
            <div>So there are 3 vertices and 2 edges in the point SF.</div>
            <div><br>
            </div>
            <div>   Matt</div><div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In
              case it is a bug, I have attached a patch that fixes this
              by using the closure of the original partition instead.<br>
              <br>
              Thanks and kind regards<span><font color="#888888"><br>
                  Michael<br>
                </font></span></blockquote>
          </div></div>
          <br>
          <br clear="all"><span><font color="#888888">
          <div><br>
          </div>
          -- <br>
          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
        </font></span></div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br>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></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>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>