<div class="gmail_quote">On Thu, Nov 24, 2011 at 6:56 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="HOEnZb"><div class="h5">On Thu, Nov 24, 2011 at 6:41 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Thu, Nov 24, 2011 at 18:30, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>In any event, this business of storing explicit ranks/offsets for the ghost indices is sort of antithetical to the current</div>

<div>PetscLayout-based approach of indices having parallel semantics from the outset.  A lot of conceptual difficulties </div><div>in Sieve and MOAB (and the need for the extra objects such as Overlap and ParallelComm (sic!)) stem from a lack of </div>





<div>a global address space. </div></blockquote><div><br></div></div><div>Global addresses and (rank, offset) are equivalent modulo MPI_Scan() which costs essentially the same as MPI_Reduce(). Not free, but not huge when done in setup. I think global indices are usually easier for users to play with (if they need anything that has global semantics, local indices combined with a local-to-global map is even better when sufficient), but they eventually need to be converted to (rank, offset) for communication (MPI does not know about a "global index" and I don't think it should.)</div>



</div>
</blockquote></div><br></div></div>I think the idea of a local point of view is fundamental, not just for parallelism. We use LocalToGlobal mappings in FS so that yu do not have<div>to know about other fields, just the same as you should not have to know about other processes.</div>

</blockquote><div><br></div><div>Something has to know about the global layout.  In the example about it's the PetscLayout in the Vec or Mat being split.</div><div>If the PetscLayout takes on a different form, then everything that relies on range in it has to be redesigned. </div>

<div>One way to approach this is to make every PETSc object interact with PetscLayout through an API that hides its details,</div><div>not but looking at the "private" struct members directly. I think that's the right place to start.</div>

<div><br></div><div>Dmitry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div>   Matt<div class="im"><br clear="all"><div><br></div>-- <br>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<br>
</div></div>
</blockquote></div><br>