dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Apr 10, 2008 at 04:12:51PM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Thu, Apr 10, 2008 at 12:48:16PM +0100, Garth N. Wells wrote:
> >>
> >> Kent-Andre Mardal wrote:
> >>> The new functions are the functions that have been added to
> >>> GenericVector, right ? 
> >>>
> >>> I guess you refer e.g. to the fact that axpy have been re-implemented in
> >>> terms of a for loop instead of using the template expression y += a*x ?
> >> Yes.
> >>
> >>> The reason for this re-implementation is the operators implmented in
> >>> GenericVector. These operators mess up the operators previously
> >>> implemented by ublas_vector. 
> >>>
> >>> What is the performance penalty ? 
> >>>
> >> uBLAS is better at performing various operations than we are. The 
> >> current implementation involves element access and the extra function 
> >> calls do have an impact for the size matrices we work with. We did 
> >> extensive testing some time ago, and the general conclusion was that 
> >> direct access to uBLAS functions is important for smallish vectors.
> >>
> >> An unattractive feature of uBlasVector is that we have a mix-mash of 
> >> functionality from the uBlasVector interface and the ublas_vector 
> >> interface (including member functions with the same name). Should 
> >> uBlasVector simply own a ublas_vector and uBlasVector can return the 
> >> pointer to the ublas_object is a user needs it? This would mirror the 
> >> PETScVector design. Then we would know for sure where functions are 
> >> coming from.
> > 
> > Sounds good to me. Martin suggested exactly this just this morning,
> > but I said I think Garth won't like it.
> >
> 
> I liked being able to access the extensive uBLAS functionality directly 
> without overhead, but that's getting too hard now with the new la design 
> so I'm happy to follow the PETScVector design. So let's do it and also 
> follow the same design for for uBlasMatrix.

Good. It will require some work to go through the ODE solver classes
and the uBlas Krylov solver classes to make sure they don't
deteriorate performance-wise with the change.

> > Anyway, it makes perfect sense to do this. Just as for PETSc, we can
> > have mat() and vec(). It should also remove the need for all the scary
> > template programming we have now in uBlasFoo?
> >
> 
> We don't have much of that in uBlasVector because uBlasVector is tied to 
> a particular uBLAS data type, but we will probably still need it in 
> uBlasMatrix because various underlying matrices can be used (dense, 
> sparse, row major, column major, etc).

ok.

-- 
Anders