dolfin team mailing list archive

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

On Wed, 2006-03-29 at 16:59 -0600, Anders Logg wrote:
> 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.
> 

I've done some benchmarking for various ways to set the values by index
and to retrieve them by index in a small matrices. With the way we
currently use PETSc, it's about 500-600 times slower for insertion that
any other technique (this is for dense PETSc matrices). This is due to
the calls 

  MatAssemblyBegin(A, MAT_FINAL_ASSEMBLY);
  MatAssemblyEnd(A, MAT_FINAL_ASSEMBLY); 

after inserting each value each value.

For a full 6x6 matrix which is assembled 1e7 times, the normalised
timings were

PETSc*:                   25
Boost multi_array class:  8
Boost ublas::matrix:      1.7
std::vector based matrix: 4.8
standard array:           1

*with MatAssemblyBegin(..) and MatAssemblyEnd(..) called only after the
insertion of all 6x6 terms. 

The timings for retrieving values are similar. Based on this, I think a
simplified version of the old DenseMatrix class would be best (at least
for my applications). If we're willing to accept a boost dependency,
uBlas is very nice.  

Garth

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