<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Matt,<br>
      <br>
      Are there any updates on this?<br>
      <br>
      Thanks,<br>
      <br>
      Michael<br>
      <br>
      On 23/02/14 20:50, Matthew Knepley wrote:<br>
    </div>
    <blockquote
cite="mid:CAMYG4GnSdP8t9dxKpyujXit+U7hgeEj61RbnbyeFQVRqVQYT0A@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Fri, Feb 21, 2014 at 6:56 AM,
            Michael Lange <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:michael.lange@imperial.ac.uk"
                target="_blank">michael.lange@imperial.ac.uk</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div>Hi Matt,<br>
                  <br>
                  Have you had a chance to think about the cell overlap
                  problem? I'm proposing to make the center dimension a
                  general Plex attribute with the current behaviour as
                  the default. We can then generate the cell overlap in
                  DMPlexDistribute according to the center dimension
                  using a utility function for point adjacency,
                  something like DMPlexGetAdjacentPoints(dm, p). <br>
                  <br>
                  I'm happy to provide a pull request for this change,
                  just tell me if you agree with this approach or if you
                  see any problems.<br>
                </div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>Yes, you are correct in this. We are having another
              discussion on petsc-maint about the kinds of partitions
              that are</div>
            <div>appropriate for different problems. I will try and get
              through this as quickly as I can, and I will solicit your
              feedback</div>
            <div>when I get the plan for implementation done.</div>
            <div><br>
            </div>
            <div>  Thanks,</div>
            <div><br>
            </div>
            <div>     Matt</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div text="#000000" bgcolor="#FFFFFF">
                <div> Thanks and kind regards,<br>
                  <br>
                  Michael
                  <div>
                    <div class="h5"><br>
                      <br>
                      <br>
                      On 03/02/14 11:32, Michael Lange wrote:<br>
                    </div>
                  </div>
                </div>
                <div>
                  <div class="h5">
                    <blockquote type="cite">
                      <div>Hi Matt,<br>
                        <br>
                        On 31/01/14 05:11, Matthew Knepley wrote:<br>
                      </div>
                      <blockquote type="cite">
                        <div dir="ltr">
                          <div class="gmail_extra">
                            <div class="gmail_quote">On Tue, Jan 28,
                              2014 at 8:57 AM, Michael Lange <span
                                dir="ltr"><<a moz-do-not-send="true"
href="mailto:michael.lange@imperial.ac.uk" target="_blank">michael.lange@imperial.ac.uk</a>></span>
                              wrote:<br>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">Hi,<br>
                                <br>
                                I noticed that the cell overlap created
                                during DMPlexDistribute does not include
                                cells that only share a vertex but no
                                edge with an owned cell. This causes
                                problems when performing local assembly
                                (MAT_IGNORE_OFF_PROC_ENTRIES) based on
                                information from the plex, because one
                                contribution to the shared vertex is
                                missing.<br>
                                <br>
                                As an example consider the 2x2 square
                                with 8 cells (attached). When
                                partitioned across two ranks with
                                overlap=1 each rank owns 4 cells and in
                                the current version knows about 2 halo
                                cells, giving a total of 6 cells. The
                                central vertex, however, touches 3 owned
                                and 3 non-owned cells, one of which
                                doesn't share an edge with any owned
                                cells. So, in order to correctly
                                assemble the central vertex locally, the
                                rank owning it needs to know about 7
                                cells in total.<br>
                                <br>
                                I have attached a patch that fixes this
                                problem by going over the inverse
                                closure of all vertices associated with
                                a given cell instead of using the
                                provided edge graph. Please tell me what
                                you think and whether there might be an
                                easier way to fix this.<br>
                              </blockquote>
                              <div><br>
                              </div>
                              <div>This is true, but unfortunately not
                                what everyone wants. FVM people want
                                just what is there now. This</div>
                              <div>same choice comes up in
                                preallocation. There I have put in the
                                "center dimension" which says what</div>
                              <div>kind of point do you use for the
                                center, vertex or face? I guess we need
                                that here as well.</div>
                            </div>
                          </div>
                        </div>
                      </blockquote>
                      Yes, I think the center dimension is exactly what
                      we need here, because my proposed fix is to switch
                      from using star(cone(p)) to star(closure(p)). So,
                      do you want to make the center dimension a general
                      Plex attribute and move the Set/Get functions to
                      plex.c? If so, what would be the default? In that
                      case a DMPlexGetAdjacentPoints(dm, p) function
                      might also be helpful if this is used in several
                      places? I'm happy to provide a pull request, just
                      tell me how you want this to be structured. <br>
                      <br>
                      Thanks<br>
                      Michael<br>
                    </blockquote>
                    <br>
                  </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>
    </blockquote>
    <br>
  </body>
</html>