[petsc-dev] Cell overlap in DMPlexDistribute

[Matthew Knepley]

On Fri, Feb 21, 2014 at 6:56 AM, Michael Lange <michael.lange at imperial.ac.uk
> wrote:

>  Hi Matt,
>
> 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).
>
> 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.
>

Yes, you are correct in this. We are having another discussion on
petsc-maint about the kinds of partitions that are
appropriate for different problems. I will try and get through this as
quickly as I can, and I will solicit your feedback
when I get the plan for implementation done.

  Thanks,

     Matt


> Thanks and kind regards,
>
> Michael
>
>
>
> On 03/02/14 11:32, Michael Lange wrote:
>
> Hi Matt,
>
> On 31/01/14 05:11, Matthew Knepley wrote:
>
>  On Tue, Jan 28, 2014 at 8:57 AM, Michael Lange <
> michael.lange at imperial.ac.uk> wrote:
>
>> Hi,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>
>  This is true, but unfortunately not what everyone wants. FVM people want
> just what is there now. This
> same choice comes up in preallocation. There I have put in the "center
> dimension" which says what
> kind of point do you use for the center, vertex or face? I guess we need
> that here as well.
>
> 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.
>
> Thanks
> Michael
>
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140223/17e70b37/attachment.html>