<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Fri, Aug 31, 2018 at 2:20 PM Smith, Barry F. <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
    PETSc developers,<br>
<br>
       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?<br>
<br>
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)<br></blockquote><div><br></div><div>DMCreateInterpolation() says nothing about nesting, and in fact lets people create arbitrary algebraic interpolation. For DMPlex, we support</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) non-nested DM to DM. DMPlexComputeInterpolatorGeneral(DM, DM, Mat, void *); (and what does "local portion" mean?) (also the usr context? is not used).<br></blockquote><div><br></div><div>We can take out "local portion". That was me talking to myself.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) DM to a set of points (mesh to points)  with DMInterpolationInfo and the routines  DMInterpolationEvaluate() etc. Is this fully implemented for DMPLEX, DMDA?</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Parallel, does the user need to know which process the points are on or is that all figured out?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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)?<br></blockquote><div><br></div><div>This is supported. However, what is currently in there is custom code Dave wrote which only works for P1. We now have code</div><div>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</div><div>tests. However, we need some more time to fully integrate it into the interface currently in DMSwarm.</div><div><br></div><div>Another problem is that Dave has a different definition of points than the plasma people. We need a nice way</div><div>to switch between these perspectives when doing interpolation, which is what will take us a little time when we are integrating.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5) Points to points? (Done indirectly by interpolating to a DM then back to the other points)?<br></blockquote><div><br></div><div>Yes, that is how I would do it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is a routine DMPlexInterpolate() is this mis-named/confusing thing? Interpolate seems to mean something slight different here.<br></blockquote><div><br></div><div>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</div><div>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</div><div>and vertices. Better name?</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   All of this explanation could go into the users manual (or FAQ for now).<br>
<br>
   Thanks for any explanations,<br>
<br>
   Barry<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>