dolfin team mailing list archive

["Garth N. Wells" <g.n.wells@xxxxxxxxxx>]

On Wed, 2006-03-29 at 16:56 -0600, Anders Logg wrote:
> On Thu, Mar 30, 2006 at 12:51:13AM +0200, Garth N. Wells wrote:
> > On Wed, 2006-03-29 at 16:45 -0600, Anders Logg wrote:
> > > On Thu, Mar 30, 2006 at 12:38:36AM +0200, Garth N. Wells wrote:
> > > 
> > > > > Another option would be to dig up the old DenseMatrix (attached) from
> > > > > before we removed it in version 0.5.5.
> > > > > 
> > > > 
> > > > I took a look at this earlier today. I thought that if we followed this
> > > > approach, it was worth considering an external library to cut down on
> > > > code and while offer the same or more features.
> > > 
> > > Agree!
> > > 
> > > > > But before we do anything more about this, it would be good to see
> > > > > some benchmarks to motivate why this can't be handled by PETSc. We use
> > > > > a lot of small PETSc matrices in the ODE solvers and it seems to work
> > > > > ok.
> > > > > 
> > > > 
> > > > I'll take a look. Are you creating PETSc dense matrices, or are you
> > > > using dolfin::Matrix?
> > > > 
> > > > Garth
> > > 
> > > Just Matrix without any options.
> > > 
> > 
> > My experience is that this is extremely slow, particularly when
> > accessing values. You have all the overhead of the the sparse storage
> > scheme.
> > 
> > Garth
> 
> What if we add Matrix::dense to the matrix types (mapped to PETSc
> MATDENSE)? Would that help?
> 

Might do. I'll set up some benchmarks to check it out.

Garth

> /Anders
> 
> _______________________________________________
> DOLFIN-dev mailing list
> DOLFIN-dev@xxxxxxxxxx
> http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev