dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Mar 30, 2006 at 12:58:37AM +0200, Garth N. Wells wrote:
> 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

Great. Let's hope it's enough. It would be the simplest solution.

/Anders