<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 1, 2017 at 10:51 AM, Lawrence Mitchell <span dir="ltr"><<a href="mailto:lawrence.mitchell@imperial.ac.uk" target="_blank">lawrence.mitchell@imperial.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 25/05/17 21:00, Matthew Knepley wrote:<br>
> On Thu, May 25, 2017 at 2:22 PM, Lawrence Mitchell<br>
> <<a href="mailto:lawrence.mitchell@imperial.ac.uk">lawrence.mitchell@imperial.<wbr>ac.uk</a><br>
</span>> <mailto:<a href="mailto:lawrence.mitchell@imperial.ac.uk">lawrence.mitchell@<wbr>imperial.ac.uk</a>>> wrote:<br>
<span class="gmail-">><br>
><br>
>     > On 25 May 2017, at 20:03, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a> <mailto:<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>>> wrote:<br>
>     ><br>
>     ><br>
>     > Hmm, I thought I made adjacency per field. I have to look. That way, no problem with the Stokes example. DG is still weird.<br>
><br>
>     You might, we don't right now.  We just make the topological<br>
>     adjacency that is "large enough", and then make fields on that.<br>
><br>
>     ><br>
>     > 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,<br>
>     > wait for me to do it. Its here<br>
>     ><br>
>     > <a href="https://bitbucket.org/petsc/petsc/src/01c3230e040078628f5e559992965c1c4b6f473d/src/dm/impls/plex/plexdistribute.c?at=master&fileviewer=file-view-default#plexdistribute.c-239" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/src/<wbr>01c3230e040078628f5e559992965c<wbr>1c4b6f473d/src/dm/impls/plex/<wbr>plexdistribute.c?at=master&<wbr>fileviewer=file-view-default#<wbr>plexdistribute.c-239</a><br>
>     <<a href="https://bitbucket.org/petsc/petsc/src/01c3230e040078628f5e559992965c1c4b6f473d/src/dm/impls/plex/plexdistribute.c?at=master&fileviewer=file-view-default#plexdistribute.c-239" rel="noreferrer" target="_blank">https://bitbucket.org/petsc/<wbr>petsc/src/<wbr>01c3230e040078628f5e559992965c<wbr>1c4b6f473d/src/dm/impls/plex/<wbr>plexdistribute.c?at=master&<wbr>fileviewer=file-view-default#<wbr>plexdistribute.c-239</a>><br>
>     ><br>
>     > I am more than willing to make this overridable by the user through function composition or another mechanism.<br>
><br>
>     Hmm, that naive thing of just modifying the XXX_Support_Internal<br>
>     to compute with DMPlexGetTransitiveClosure rather than<br>
>     DMPlexGetCone didn't do what I expected, but I don't understand<br>
>     the way this bootstrapping is done very well.<br>
><br>
><br>
> It should do the right thing. Notice that you have to be careful about<br>
> the arrays that you use since I reuse them for efficiency here.<br>
> What is going wrong?<br>
<br>
</span>Coming back to this, I think I understand the problem a little better.<br>
<br>
Consider this mesh:<br>
<br>
+----+<br>
|\ 3 |<br>
| \  |<br>
|2 \ |<br>
|   \|<br>
+----+<br>
|\ 1 |<br>
| \  |<br>
|0 \ |<br>
|   \|<br>
+----+<br>
<br>
Let's say I run on 3 processes and the initial (non-overlapped) cell<br>
partition is:<br>
<br>
rank 0: cell 0<br>
rank 1: cell 1 & 2<br>
rank 2: cell 3<br>
<br>
Now I'd like to grow the overlap such that any cell I can see through<br>
a facet (and its closure) lives in the overlap.<br>
<br>
So great, I just need a new adjacency relation that gathers<br>
closure(support(point))<br>
<br>
But, that isn't right, because now on rank 0, I will get a mesh that<br>
looks like:<br></blockquote><div><br></div><div>I do not understand why you think its not right. Toby and I are trying to push a formalism for</div><div>this understanding, in <a href="https://arxiv.org/abs/1508.02470">https://arxiv.org/abs/1508.02470</a>. So you say that if sigma is a dual</div><div>basis function associated with point p, then the support of its matching psi, sigma(psi) = 1</div><div>in the biorthogonal bases, is exactly star(p).</div><div><br></div><div>So, if you have no sigma sitting on your vertex, who cares if you put that extra edge and node</div><div>in. It will not affect the communication pattern for dofs. If you do, then shouldn't you be including</div><div>that edge?</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
+<br>
|<br>
|<br>
|<br>
|<br>
+----+<br>
|\ 1 |<br>
| \  |<br>
|0 \ |<br>
|   \|<br>
+----+<br>
<br>
Because I grab all the mesh points in the adjacency of the initial cell:<br>
<br>
+<br>
|\<br>
| \<br>
|0 \<br>
|   \<br>
+----+<br>
<br>
And on the top vertex that pulls in the facet (but not the cell).<br>
<br>
So I can write a "DMPlexGetAdjacency" information that only returns<br>
non-empty adjacencies for facets.  But it's sort of lying about what<br>
it does now.<br>
<br>
Thoughts?<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Lawrence<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">http://www.caam.rice.edu/~mk51/</a><br></div></div></div>
</div></div>