<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 27, 2010, at 8:13 AM, Aron Ahmadia wrote:</div><br class="Apple-interchange-newline"><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> 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><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">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 class="im"><br>
On Fri, Aug 27, 2010 at 6:42 AM, Matthew Knepley <<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> 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">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">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></body></html>