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

[Matthew Knepley]

On Fri, Aug 31, 2018 at 4:11 PM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

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

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/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180901/46c50ddc/attachment-0001.html>