dolfin team mailing list archive

["Martin Sandve Alnæs" <martinal@xxxxxxxxx>]

2007/3/13, Anders Logg <logg@xxxxxxxxx>:
> On Tue, Mar 13, 2007 at 05:03:14PM +0100, Garth N. Wells wrote:
> > Martin Sandve Alnæs wrote:
> > > 2007/3/12, Anders Logg <logg@xxxxxxxxx>:
> > >> Here, matrix_sparsity_pattern is a vector<set<int>> and the nodemap
> > >> function is the old (non-UFC) name of the tabulate_dofs() function.
> > >>
> > >> Is this the same as your implementation? (Other than splitting the
> > >> insertion into a separate call insert_block()?)
> > >
> > > Looks pretty much the same.
> > >
> > > Another thing to consider, is a GenericSparsityPattern class with
> > > insert(...) similar to GenericMatrix::add(...). F.ex. Epetra has an
> > > insertion function like this in Epetra_CRSGraph, and other matrix
> > > libraries may have one as well. Then maybe your
> > > GenericMatrix::init(m,n) can be replaced/complemented by a
> > > GenericMatrix::init(GenericSparsityPattern &).
> > >
> >
> > I think that we'll end up with something like this.
> >
> > Garth
>
> Yes, this sounds like a good idea.
>
> Garth, do we want to split the DofMap functionality into DofMap
> and SparsityPattern? A DofMap could compute or return a
> SparsityPattern. It seems more natural to initialize a tensor (matrix)
> with a SparsityPattern than by a DofMap.
>
> Martin, why the name *Generic*SparsityPattern? Do you have subclasses
> of GenericSparsityPattern?

The idea was:

class EpetraSparsityPattern: public Epetra_CRSGraph, public
GenericSparsityPattern
( // curly braces dont work here...
 virtual void insert(...) ( InsertBlock(...); )
)

class STLSparsityPattern: public GenericSparsityPattern
(
 vector<set<int>> pattern;
 virtual void insert(...) ( ... )
)

Currently I don't have this class, I have duplicated the sparsity
pattern building algorithm instead. To initialize an Epetra_CRSMatrix
you need an Epetra_CRSGraph, which has its own insert(...)-like
function. This might handle some parallell issues transparently as
well, I don't know what that would be. On the other hand, an
Epetra_CRSGraph can probably be initialized from a raw array with the
sparsity pattern.

Note that an Epetra_CRSGraph also depends on a range map and domain
map, which contains the set of local indices for a distributed vector.
So it mixes the sparsity pattern and distribution pattern. The
distribution pattern of a vector should probably also be created by
the DofMap. We also need to build the sparsity pattern and
distribution patterns for vectors and matrices over a submesh for
multi-physics problems.

This might eliminate the need for a factory object for matrices and
vectors of various kinds. I currently have this built into subclasses
of the FEMAssembler, but I'm not too happy with that design, it's not
very flexible.

martin