dolfin team mailing list archive

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

Kent Andre wrote:
> Hi, 
> 
> Mikael Mortensen has written a function compress_sparse for removing all
> the non-zeros in a Matrix. There can be many! For instance for 
> a vector mass or stiffness matrix in 3D, 2/3 or more of the matrix
> entries are zeros. Naturally, in such applications, we get a big speed
> up. 
> 

Nice.

> Mikael has put this function in GenericMatrix. Is this the right place? 
> Should a new matrix be made instead ?
>

The implementation shouldn't go in GenericMatrix. It could be made pure
virtual in GenericMatrix. The backends differ in how they can best be
compressed, some don't need it (like dense matrices) and some backends
supply their own functions to do this, e.g.

http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatCompress.html

and the already implemented uBLASMatrix::compress(...) function.

We could create a file in dolfin/la called something like
'GenericAlgortithms', 'GenericTools' or 'GenericMethods' which contains
functions that manipulate GenericFoo and/or GenericMatrix objects. The
functions could be free functions or static member functions.

> The only side effect I can think of is that the sparsity pattern is
> changed. Hence, the matrix may no longer be added to another 
> matrix created using the same function space.  
>

Two issues are:

  - For repeated assembly, the matrix would need to be re-initialised at
each assembly, so the linear solve speed-up may be lost.

  - A compress function should work in parallel.

Garth


> Kent
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dolfin
> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dolfin
> More help   : https://help.launchpad.net/ListHelp