<div dir="ltr"><meta charset="utf-8"><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13.2px; border-collapse: collapse; "><div>Barry,</div><div><br></div>I was being snippy, DAGetMatrix is the only one I know of that acts unexpectedly.<div>
<br></div><div>Still, when working with Vec, you expect Get/Restore to modify data in the Vec itself, which breaks for DAs since a DA has no internal Vec storage. Unless you are willing to append 'Work' somewhere into the names of the work vector routines, I don't see an obvious solution.</div>
<div><br></div><font color="#888888"><div>A</div></font></span><br><div class="gmail_quote">On Fri, Aug 27, 2010 at 4:27 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@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 style="word-wrap:break-word"><br><div><div class="im"><div>On Aug 27, 2010, at 8:13 AM, Aron Ahmadia wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Not to mention the various Get routines that are actually used to create things, such as DAGetMatrix. Still, the idea of a pool of work vectors makes sense, I was just trying to wrap my head around the actual use for those routines.</div>
</blockquote><div><br></div></div><div> Aron,</div><div><br></div> DAGetMatrix() is actually a bug and should be DACreateMatrix() (or maybe better DACreateMat() while the DACreateGlobalVector() and friends should really be DACreateGlobalVec()). </div>
<div><br></div><div> Are there others beside DAGetMatrix() that are incorrect with gets that should be creates?</div><div><br></div><div> Thanks</div><div><br></div><div> Barry</div><div><br></div><div> It would actually be nice if we made DACreateGlobal/LocalVector() so light-weight that it could be used for work vectors (instead of needing a different set of light weight get routines) but then we would need DADestroyGlobal/Vector() to handle putting back in the free list or need to modify VecDestroy() to handle not actually destroying but managing a free list). And there is also the issue of zeroing or not zeroing the Vec initially.</div>
<div>This is why we still have the Create and Get versions.</div><div><div></div><div class="h5"><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div>
<br></div><div>A<br><br><div class="gmail_quote">On Fri, Aug 27, 2010 at 4:06 PM, 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">
Except VecGetArray, etc, which operate a "pool" of one object.<br>
I think this may be the root cause of confusion.<br>
<font color="#888888"><br>
Dmitry.<br>
</font><div><br>
On Fri, Aug 27, 2010 at 6:42 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> wrote:<br>
</div><div><div></div><div>> Simply, in PETSc, getFoo() and restoreFoo() operate an object pool.<br>
> Matt<br>
><br>
> On Fri, Aug 27, 2010 at 11:23 AM, Jed Brown <<a href="mailto:jed@59a2.org" target="_blank">jed@59a2.org</a>> wrote:<br>
>><br>
>> On Fri, 27 Aug 2010 14:13:01 +0300, Aron Ahmadia<br>
>> <<a href="mailto:aron.ahmadia@kaust.edu.sa" target="_blank">aron.ahmadia@kaust.edu.sa</a>> wrote:<br>
>> > What exactly is the purpose of these routines then? Is there a global<br>
>> > Vector associated with a DA? If so, why are the values uninitialized?<br>
>><br>
>> It's common to need work vectors in places like residual evaluation and<br>
>> Jacobian assembly. There is a little bit of setup cost to allocate a<br>
>> new vector each time, so usually we'd prefer that they be persistent and<br>
>> just reuse them. One option would be to make the user manage this<br>
>> themselves, but that's error prone because it's easy to accidentally<br>
>> alias the work vectors, so instead the DA keeps a cache of vectors. It<br>
>> starts out empty, and each time you call DAGetGlobalVector(), the cache<br>
>> is searched for an available vector. If none are found, a new one is<br>
>> allocated and the cache grows by one. DARestoreGlobalVector() checks a<br>
>> vector back in so it may be used elsewhere. These vectors are destroyed<br>
>> in DADestroy().<br>
>><br>
>> Jed<br>
><br>
><br>
><br>
> --<br>
> What most experimenters take for granted before they begin their experiments<br>
> is infinitely more interesting than any results to which their experiments<br>
> lead.<br>
> -- Norbert Wiener<br>
><br>
</div></div></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>