[petsc-users] DMPlex distribution with FVM adjacency

[Stefano Zampini]

> On Jun 1, 2017, at 5:51 PM, Lawrence Mitchell <lawrence.mitchell at imperial.ac.uk> wrote:
> 
> On 25/05/17 21:00, Matthew Knepley wrote:
>> On Thu, May 25, 2017 at 2:22 PM, Lawrence Mitchell
>> <lawrence.mitchell at imperial.ac.uk
>> <mailto:lawrence.mitchell at imperial.ac.uk>> wrote:
>> 
>> 
>>> On 25 May 2017, at 20:03, Matthew Knepley <knepley at gmail.com <mailto:knepley at gmail.com>> wrote:
>>> 
>>> 
>>> Hmm, I thought I made adjacency per field. I have to look. That way, no problem with the Stokes example. DG is still weird.
>> 
>>    You might, we don't right now.  We just make the topological
>>    adjacency that is "large enough", and then make fields on that.
>> 
>>> 
>>> That seems baroque. So this is just another adjacency pattern. You should be able to easily define it, or if you are a patient person,
>>> wait for me to do it. Its here
>>> 
>>> https://bitbucket.org/petsc/petsc/src/01c3230e040078628f5e559992965c1c4b6f473d/src/dm/impls/plex/plexdistribute.c?at=master&fileviewer=file-view-default#plexdistribute.c-239
>>    <https://bitbucket.org/petsc/petsc/src/01c3230e040078628f5e559992965c1c4b6f473d/src/dm/impls/plex/plexdistribute.c?at=master&fileviewer=file-view-default#plexdistribute.c-239>
>>> 
>>> I am more than willing to make this overridable by the user through function composition or another mechanism.
>> 
>>    Hmm, that naive thing of just modifying the XXX_Support_Internal
>>    to compute with DMPlexGetTransitiveClosure rather than
>>    DMPlexGetCone didn't do what I expected, but I don't understand
>>    the way this bootstrapping is done very well.
>> 
>> 
>> It should do the right thing. Notice that you have to be careful about
>> the arrays that you use since I reuse them for efficiency here.
>> What is going wrong?
> 
> Coming back to this, I think I understand the problem a little better.
> 
> Consider this mesh:
> 
> +----+
> |\ 3 |
> | \  |
> |2 \ |
> |   \|
> +----+
> |\ 1 |
> | \  |
> |0 \ |
> |   \|
> +----+
> 
> Let's say I run on 3 processes and the initial (non-overlapped) cell
> partition is:
> 
> rank 0: cell 0
> rank 1: cell 1 & 2
> rank 2: cell 3
> 
> Now I'd like to grow the overlap such that any cell I can see through
> a facet (and its closure) lives in the overlap.
> 

Lawrence, why do you need the closure here? Why facet adjacency is not enough? 

> So great, I just need a new adjacency relation that gathers
> closure(support(point))
> 
> But, that isn't right, because now on rank 0, I will get a mesh that
> looks like:
> 
> +
> |
> |
> |
> |
> +----+
> |\ 1 |
> | \  |
> |0 \ |
> |   \|
> +----+
> 
> Because I grab all the mesh points in the adjacency of the initial cell:
> 
> +
> |\
> | \
> |0 \
> |   \
> +----+
> 
> And on the top vertex that pulls in the facet (but not the cell).
> 
> So I can write a "DMPlexGetAdjacency" information that only returns
> non-empty adjacencies for facets.  But it's sort of lying about what
> it does now.
> 
> Thoughts?
> 
> Lawrence
>