[petsc-dev] Gathering information: types of interpolations in PETSc and which ones are supported?

[Smith, Barry F.]

> On Aug 31, 2018, at 2:52 PM, Matthew Knepley <knepley at gmail.com> wrote:
> 
> On Fri, Aug 31, 2018 at 2:20 PM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:
> 
>     PETSc developers,
> 
>        There are a variety of "interpolation" modules in PETSc but the documentation is scattered (mostly missing). Could everyone who knows anything about the various modules provide a little information about which modes exist as interfaces and which have actual supporting code and expected usage? Anything duplicative?
> 
> 1) nested DM to DM (mesh to mesh) of the same type of DM seems to be supported for DMDA and DMPLEX using DMCreateInterpolation(). But what is DMPlexComputeInterpolatorNested(DM, DM, Mat, void *), how is it different? (Note usr context is not used)
> 
> DMCreateInterpolation() says nothing about nesting, and in fact lets people create arbitrary algebraic interpolation. For DMPlex, we support
> both nested and non-nested MG (Patrick says there is a subtle bug in non-nested), but my tests pass for this. The Nested case is obviously much easier and has a fixed element matrix, whereas non-nested uses point location.
>  
> 2) non-nested DM to DM. DMPlexComputeInterpolatorGeneral(DM, DM, Mat, void *); (and what does "local portion" mean?) (also the usr context? is not used).
> 
> We can take out "local portion". That was me talking to myself.

    Why do DMPlexComputeInterpolatorNested() and DMPlexComputeInterpolatorGeneral() exist if DMCreateInterpolation()  handles both nested and non-nested? Does DMCreateInterpolation() use them? If so they should be made private and there name changed: for example 

DMCreateInterpolation_Plex_Nested() and DMCreateInterpolation_Plex_General(). Having multiple interfaces with different names that do the same thing is very confusing and not the way we do things in PETSc.


>  
> 3) DM to a set of points (mesh to points)  with DMInterpolationInfo and the routines  DMInterpolationEvaluate() etc. Is this fully implemented for DMPLEX, DMDA?
> 
> This relies on the DMLocatePoints(), which I think was implemented for both, but if it isn't for DMDA, its trivial and we should do it.
>  
> Parallel, does the user need to know which process the points are on or is that all figured out?
> 
> That is figured out. Actually, its most of the reason that this exists. However, I wrote this a long time ago. It should go away in favor of DMSwarm.
>  
> 4) Points to a DM. Is this supported (should be?) by DMSWARM? In fact should 3) work with DMSWARM as the set of points and not have its own construct (DMInterpolationInfo)?
> 
> This is supported. However, what is currently in there is custom code Dave wrote which only works for P1. We now have code
> that does this for any element and in all dimensions. Its in a branch and will get merged shortly (next week) since it passes all
> tests. However, we need some more time to fully integrate it into the interface currently in DMSwarm.
> 
> Another problem is that Dave has a different definition of points than the plasma people. We need a nice way
> to switch between these perspectives when doing interpolation, which is what will take us a little time when we are integrating.
>  
> 5) Points to points? (Done indirectly by interpolating to a DM then back to the other points)?
> 
> Yes, that is how I would do it.
>  
> There is a routine DMPlexInterpolate() is this mis-named/confusing thing? Interpolate seems to mean something slight different here.
> 
> Yes. Unfortunately, the same word is used by topology people. I am willing to change this since very few people use it, when they do its
> only used once, and its completely different. It refers to figuring out the edges and faces automatically in a mesh when you get only cells
> and vertices. Better name?
> 
>   Thanks,
> 
>      Matt
>  
>    All of this explanation could go into the users manual (or FAQ for now).
> 
>    Thanks for any explanations,
> 
>    Barry
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 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
> 
> https://www.cse.buffalo.edu/~knepley/