On Thu 2009-04-09 14:03, Kirk, Benjamin (JSC-EG311) wrote: > While we do not currently manage the array ourselves, what I am proposing is > that we make that step, and further to do it in the base class so all the > derived classes can benefit.
You still don't have to deal with allocating the memory. You can cache the pointer you get from VecGetArray and Epetra_MultiVector::ExtractView. You won't get the protection that you usually get from VecRestoreArray increasing the state, but you are basically managing that yourself anyway. > Aside from performance, the other major benefit is reducing the number of > external API function calls are required in general. For example, when > putting together the Epetra interface we essentially copied the petsc_vector > source and replaced the petsc api calls with their epetra counterparts. > obviously, the fewer petsc api calls we started with the easier the port > would have been. Yes, although it's not necessarily better to duplicate library functionality than to call their API for it. This can be both a performance issue (their implementation is somehow optimized, perhaps even operating on a copy residing on a GPU) and simple reduction in code duplication. A natural progression is that you manage everything yourself and invert control by implementing PETSc Vec and Epetra_Vector. Being intermediate is more error-prone because you have to know some internals of all implementations. Just something to consider. Jed
pgpc5Kk1nW6Rf.pgp
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com
_______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
