> 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.
>
> 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/
