> On Jun 1, 2017, at 5:51 PM, Lawrence Mitchell > <[email protected]> wrote: > > 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. >
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 >
