[petsc-dev] Cell overlap in DMPlexDistribute

[Michael Lange]

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.

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 <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20140221/5311c7dc/attachment.html>