dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Sat, Apr 01, 2006 at 12:05:43AM +0200, Garth N. Wells wrote:
> Quoting Anders Logg <logg@xxxxxxxxx>:
> 
> > On Fri, Mar 31, 2006 at 06:16:51PM +0200, Garth N. Wells wrote:
> > > On Fri, 2006-03-31 at 10:10 -0600, Robert C.Kirby wrote:
> > > > >
> > > > > The more I look at it, the more I like it.
> > > > >
> > > > > For the benchmarks I made, there was no optimisation (it was  
> > > > > missing from dolfin-config --cflags). When using optimisation,  
> > > > > uBlas outperforms the simple functions I wrote for inserting and  
> > > > > retrieving values from an array. It also provides a LU solver  
> > > > > (which I need to compute inverses of small matrices).
> > > > >
> > > > > It compiled fine with the Intel Linux compiler, and I'm testing it  
> > > > > now under Cygwin.
> > > > >
> > > > 
> > > > Can you install just ublas (without the boost build system), or do  
> > > > you have to go through the whole boost build process?
> > > > 
> > > 
> > > There is no need build boost when using ublas.
> > > 
> > > If you want to build uBlas, it does have it's own build system but there
> > > is also a configure script so you can do the usual ./configure, make
> > > install.
> > > 
> > > Garth
> > 
> > It seems obvious we need something other than PETSc for dense linear
> > algebra and ublas seems to be a good option.
> > 
> > How do we make it fit into DOLFIN? There are some different options:
> > 
> > 1. Wrap it as we do with most other stuff, so we would create
> > something like a class DenseMatrix that wraps a ublas dense matrix.
> > 
> > Then the question is how DenseMatrix interacts with the class Vector
> > which is a PETSc vector. Do we also need a DenseVector?
> 
> This would be quick, and we wouldn't have wrap many (if any functions) as uBlass
> is C++ and the functions are intuitive. If we wrap everthing, what's the point
> in using uBlas?
> 
> We would need a DenseVector to operate with a dense matrix when taking slices,
> solving, mutliplying, etc.
> 
> This could be a good start to play around with uBlas and see if it's really what
> we want.

Maybe that's the best thing, just create a DenseMatrix and DenseVector
that wrap (or inherit or typedef) the corresponding data structures in
ublas.

Then if there should be need for it, we can merge the two matrix types
Matrix (PETSc matrix) and DenseMatrix with a common interface.

Also, putting ublas in a subdirectory contrib/ublas seems like a good
option. Just make sure to put in the proper credits and license for
ublas.

Is ublas stable or do we need to track it's development to update for
new versions?

/Anders


> > 
> > Should the assembly routines be able to accept a DenseMatrix etc?
> > 
> 
> I can think of examples where this would be useful for me, but not urgent.
> 
> > 2. Use a common interface for all linear algebra: Matrix and Vector
> > which can be PETSc or ublas or ... This is similar to what we had
> > before with our own implementations in SparseMatrix and DenseMatrix,
> > only now we would wrap PETSc and ublas instead. This might impose a
> > slight overhead in addressing entries.
> > 
> > We might remove the overhead with a template solution rather than the
> > class hierarchy (envelope-letter) we used before.
> > 
> > This way, we would also need to design a common interface for both
> > dense and sparse matrices. We could do this, but it would require some
> > thought to get it right. (Or we just go ahead and implement it and to
> > get something that works...)
> > 
> 
> A truly common interface would be difficult to define as some operations will
> differ. We could define a basic set of operations which are common.
> 
> Garth
> 
> > There is a fairly new project called GLAS for Generic Linear Algebra
> > Software that aims at creating a C++ template library for linear
> > algebra with multiple backends. I don't think they have anything
> > useful yet but they seem to have a plan for handling multiple backends
> > while providing a common interface.
> > 
> > 3. Just use ublas from within DOLFIN the way we use STL in some
> > places.
> > 
> > I'm very keen on keeping a simple user interface so in my ideal world
> > there is just one class Matrix and one class Vector (perhaps with
> > multiple backends).
> > 
> > /Anders
> > 
> > _______________________________________________
> > DOLFIN-dev mailing list
> > DOLFIN-dev@xxxxxxxxxx
> > http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev
> > 
> 

-- 
Anders Logg
Research Assistant Professor
Toyota Technological Institute at Chicago
http://www.tti-c.org/logg/