On Fri, Aug 31, 2018 at 4:11 PM Smith, Barry F. <[email protected]> wrote:
> > On Aug 31, 2018, at 2:52 PM, Matthew Knepley <[email protected]> wrote: > > > > On Fri, Aug 31, 2018 at 2:20 PM Smith, Barry F. <[email protected]> > 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. > Yes, they are called by DMCreateInterpolation() and name changes are appropriate. Matt > > > > 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/ > > -- 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/ <http://www.cse.buffalo.edu/~knepley/>
