[petsc-dev] Removing VecGetArrayPrivate3

Barry Smith bsmith at mcs.anl.gov
Wed Nov 24 18:45:44 CST 2010


   I just don't want an API explosion.  You may be falling into the trap of "just add one more method and it will make live better", pretty soon you have 10,000 methods and your stuff is unusable (at least unusable to the average Joe).


On Nov 24, 2010, at 5:00 PM, Jed Brown wrote:

> On Wed, Nov 24, 2010 at 23:47, Barry Smith <bsmith at mcs.anl.gov> wrote:
> Not sure exactly how to do this. I  think I want each implementation to do whatever checking is appropriate for its data storage. For example, one can do a VecDot() with a native Vec that is currently gotten with a read or a write but for implementations that make a copy with the get array they cannot.
>  My concern is with (1) multiple threads at some future date, and (2) respecting the API so that the code will still work if they use a non-native Vec.  Is there a compelling reason why a user should be able to VecDot while a write pointer is checked out?  Is KSPSolve_IBCGS justification?  A side-effect of enforcing this consistently is that we can provide an error message sooner when the user just forgets VecRestoreArray (instead of a potential memory leak or error at VecDestroy).
> Jed

More information about the petsc-dev mailing list