[petsc-users] DMPlex distribution with FVM adjacency

[Lawrence Mitchell]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170601/0d2627d3/attachment-0001.pgp>