[petsc-dev] What's the point of D(A/M)GetGlobalVector?

Kai Germaschewski kai.germaschewski at unh.edu
Fri Aug 27 11:00:32 CDT 2010


I think it's conceptually not right to have Get()/Restore() pairs to do
caching, but provide that feature only in special cases. Shouldn't other
places that needs temp work vectors have a similar facility? I think a
better way of handling this would be to get rid of the special
Get()/Restore() caching pairs, and rather make caching a feature of the
object itself. I.e., VecCreate() might have a pool of allocated vector data
structures + associated data storage arrays. VecDestroy() would not really
destroy a Vec but return it to the pool. Unfortunately that doesn't mix too
well with how the real setup of a vector is done later, after options and
potentially command line options have been processed, so by the time you
know what kind of vector you want, you've pretty much already filled the
data structure. And it also requires some more memory management framework
which would call upon caches to expire long-unused objects when memory is
running low.

I think a more consistent user interface would be to just have
DACreateVec(), and something like MatCreateVecs(), and then VecDestroy() the
Vec when you're done, no matter where it came from. Whether it's cached or
not is an implementation detail. Probably the first thing to figure out
would be whether caching is making an actual difference in the real world,
and if not, there's a pretty straight forward solution...

--Kai




On Fri, Aug 27, 2010 at 11:36 AM, Jed Brown <jed at 59a2.org> wrote:

> On Fri, 27 Aug 2010 10:14:30 -0500, Dmitry Karpeev <karpeev at mcs.anl.gov>
> wrote:
> > Maybe Create/Destroy isn't the right solution, but there appears to be
> > some confusion
> > about the meaning of Get/Restore in this context.  It definitely
> > differs from VecGet/RestoreArray.
> > For example: there is no guarantee that subsequent DAGetXXXs,
> > punctuated by DARestoreXXXs,
> > will give one the same object.
>
> Indeed, managing a pool has different semantics.  Is it worth looking
> for a less ambiguous/overloaded name?
>
>  Checkout/Checkin
>  Borrow/Return
>  Claim/Release
>
> Jed
>



-- 
Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245E
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100827/707ed688/attachment.html>


More information about the petsc-dev mailing list