<div dir="ltr">On Wed, Feb 13, 2013 at 12:45 AM, 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_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="im"><br>
<div class="gmail_quote">On Tue, Feb 12, 2013 at 11:34 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Is it? Maybe a more general definition of PetscSection would be better as map from (int) -> IS Matt's current usage is very restricted to only contiguous blocks of elements in a group. Need that be it? Should that be it?</blockquote>
</div><br></div>There is some hackery to ascribe "field" structure to the output of the map, but I'm skeptical of whether it belongs at this level.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
The granularity is normally very small so we certainly don't want to pay the memory or performance overhead of an IS for each output. Although I'm sure we can think up scenarios where that flexibility would be useful, I think generality in the outputs here would add significant complexity with limited practical return.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Note that PetscSection is currently accessed using function calls in inner loops. This already accounts for a noticeable amount of time for a CFD application. So we either need a coarser grained access API or we need a non-polymorphic accessor for use in hot access sites. (This is a rare case where indirect function call overhead matters.)</div>
</div>
</blockquote></div><br>I think its helpful to look at the one universal use case right now:</div><div class="gmail_extra"><br></div><div class="gmail_extra"> You would like to describe a function over a mesh, so</div><div class="gmail_extra">
associate functions with each part of the mesh and</div><div class="gmail_extra"> store coefficients of these functions.</div><div class="gmail_extra" style> This happens for:</div><div class="gmail_extra" style> mesh geometry</div>
<div class="gmail_extra" style> PDE solutions and auxiliary fields (like viscosity)</div><div class="gmail_extra" style> the mesh itself (the adjacency is a field over the points)</div><div class="gmail_extra" style>
<br></div><div class="gmail_extra" style>The inner loops Jed is referring to are structured like this</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>VecGetArray(sol, &solArray);</div><div class="gmail_extra" style>
Loop over pieces (like cell, face, etc.)</div><div class="gmail_extra" style> Get solution on this piece:</div><div class="gmail_extra" style> PetscSectionGetDof(solSection, piece, &dof), PetscSectionGetOffset(solSection, piece, &off)</div>
<div class="gmail_extra" style> pieceArray = &solArray[off];</div><div class="gmail_extra" style> Jed condenses this to DMPlexPointLocalRead(solDM, piece, solArray, &pieceArray)</div><div class="gmail_extra">
<div><br></div><div style>Thus this adds structure to the Vec sol by breaking it into irregular pieces. The lower level</div><div style>function Dof/Offset() are definitely necessary so you can reason about the operations. I think</div>
<div style>you could get away with only the array offsetting being fast, but I don't see how you make that</div><div style>fast and those slow.</div><div style><br></div><div style>Barry: > <span style="font-family:arial,sans-serif;font-size:13px">Is it? Maybe a more general definition of PetscSection would be better as map from (int) -> IS Matt's current usage is very restricted to only contiguous blocks of elements in a group. Need that be it? Should that be it?</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">I think you are missing the point here. I use this all over the place. This is PetscSection+IS. You put your</span></div>
<div style><font face="arial, sans-serif">non-contiguous indices in the IS and index into it using PetscSection. PetscSection is the composable part</font></div><div style><font face="arial, sans-serif">of this indexing-by-groups. It can be combined with IS or Vec or anything. I think it is the right building block.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif"> Matt</font></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
</div></div>