dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> 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.

If they first get hold of the pointer to the underlying uBLAS object and 
work with that, performance shouldn't be an issue.

Garth

> > > 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.