<div class="gmail_extra">On Thu, Nov 8, 2012 at 10:58 PM, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</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 id=":1zr">I don't care about expensive VecGetArray(). We do it absolutely<br>
everywhere in PETSc.<br>
We recommend that users do it. This is not a real objection.<br></div></blockquote><div><br></div><div>We normally do one VecGetArray(), then iterate over the whole local part. That's different from doing it in an inner loop. Many other packages do it in inner loops (overloading operator[] is popular among some), but that restricts the Vec types that can perform well with that package.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1zr"><div class="im">
> What other sections do users need? A trace space?<br>
<br>
</div>Blaise uses a couple for every problem. We have several in PyLith<br>
(ground surface,<br>
fault).<br></div></blockquote><div><br></div><div>What is the difference between using a PetscSection for each thing and using an IS for those points on the feature? I guess just the extra indirection (IS) versus more duplication (a PetscSection is heavier than an IS).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1zr"><div class="im">
><br>
> How do you intend to support many threads calling DMComplexVecGetClosure(),<br>
> perhaps each with multiple buffers, without expensive instructions?<br>
<br>
</div>GetClosure() is not a problem. All threads are reading from the same<br>
topology, and<br>
writing to separate output buffers. SetClosure() needs to be locked.<br></div></blockquote><div><br></div><div>You need separate buffers per thread, but we can make DMGetWorkArray() have a separate cache per thread. VecGetArray() is still not trivially cheap because we need atomics. Maybe I'm being overly paranoid, but I don't like the granularity that imposes.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1zr"><div class="im">
>><br>
>><br>
>> These are for multi-field splitting/<br>
><br>
><br>
> Clearly, but why do they need to be in PetscSection? We already need DMs<br>
> associated with fields.<br></div></div></blockquote><div><br></div><div>Answering my own question: the distinction between DM and Section is that the latter can address a discontinuous part of a Vec so addressing by field does not imply a copy.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1zr"><div class="im">
<br>
</div>Someone needs to know the splitting. If you had a DM, this info is<br>
still stuck down<br>
somewhere, so that DM is holding other DMs.</div></blockquote></div><br></div><div class="gmail_extra">It's still not clear to me why they are needed. If PetscSection is user-visible, can't they just be different Sections? DMComplexGetFieldSection(dm,field,&fsection);</div>