<p>Your function is returning objects with global semantics (they live on the global comm). The other local functions return objects that are semantically serial, although they may be logically part of something bigger. But why return an IS at all, why not an ISLocalToGlobalMapping? Too many characters?</p>

<p>I need a name for a local IS that holds indices in a local numbering. This thing has no parallel semantics, just like a local Vec. The term "local IS" is not currently taken, if we don't count you man page. Would it be acceptable to use it for my purpose?</p>

<p>Jed</p>
<p><blockquote type="cite">On Nov 20, 2010 4:15 AM, "Barry Smith" <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br><br><p><font color="#500050"><br>On Nov 19, 2010, at 6:43 PM, Jed Brown wrote:<br>
<br>> <br>> Jed<br>> <br>> [1] Barry, what is going on with DMCom...</font></p>   Looks like code that was started (maybe from cut and paste) and never finished. The manual page for function has a different name then the function, like I just stopped in the middle of editing and forgot about it.<br>

<p><font color="#500050">> The former has no implementation and the<br>> latter has no man page.  I do not think that "Local IS"...</font></p>   Well no. Local always refers to things with ghost points, while global means without ghost points. You are asking to introduce another term "Ghosted" to mean with ghost points.  Confusing/bad to introduce more terminology.<br>

<br>
   Now you could argue that using local and global was bad originally and we should use ghosted and global (or nonghosted) as our two terms. But introducing ghosted in just one place is not the solution, we would have to do it systematically through PETSc source and documentation. Though I think local and global are fine as is and don't see a need to change from local to ghosted.<br>

<br>
  Or I could be misunderstanding what you want to change.<br>
<font color="#888888"><br>
   Barry<br>
<br>
</font></blockquote></p>