On 25/05/17 21:00, Matthew Knepley wrote:
> On Thu, May 25, 2017 at 2:22 PM, Lawrence Mitchell
> <[email protected]
> <mailto:[email protected]>> wrote:
> 
> 
>     > On 25 May 2017, at 20:03, Matthew Knepley <[email protected] 
> <mailto:[email protected]>> 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.

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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to