[petsc-users] DMPlex distribution with FVM adjacency

[Matthew Knepley]

On Thu, Jun 1, 2017 at 10:51 AM, 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.
>
> 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:
>

I do not understand why you think its not right. Toby and I are trying to
push a formalism for
this understanding, in https://arxiv.org/abs/1508.02470. So you say that if
sigma is a dual
basis function associated with point p, then the support of its matching
psi, sigma(psi) = 1
in the biorthogonal bases, is exactly star(p).

So, if you have no sigma sitting on your vertex, who cares if you put that
extra edge and node
in. It will not affect the communication pattern for dofs. If you do, then
shouldn't you be including
that edge?

   Matt


> +
> |
> |
> |
> |
> +----+
> |\ 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
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener

http://www.caam.rice.edu/~mk51/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20170601/c6b3eac7/attachment.html>