dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Martin Sandve Alnæs wrote:
> Ola and I did some thinking on the SparsityPattern vs Epetra_CRSGraph
> issue, ie the case where you want the Assembler to use an external
> class for building the sparsity pattern. I think we came up with a
> nice solution, in fact it looks much like the GenericTensor::create()
> function we added earlier (as well as the ufc::form::create_*
> functions).
>
> Basically, a GenericTensor knows the type of the
> GenericSparsityPattern it expects in init(pattern). Thus we can do
> this:
>
> in application:
>   A = Matrix()
>   assemble(A, ...)
>
> in assemble:
>   pattern = A.createPattern()
>   initPattern(pattern, ...)

Is initPattern() a member function of Assembler?

And that function computes the sparsity pattern from the mesh, dofmaps
etc? Then it looks to me that it may only do so using the public
interface of GenericSparsityPattern. Is that enough to build an
Epetra_CRSGraph?

>   A.init(pattern)
>   ...
>
> with
>
> class GenericSparsityPattern
> {
>   virtual void insertBlock(rows, cols, ...)  = 0;
>   ...
> }

What does insertBlock do? Is this all we need?

> class GenericTensor
> {
>   GenericSparsityPattern * createPattern() const = 0;
>
>   // similar to what we added earlier:
>   GenericTensor * create() const = 0;
> }
>
> Then, for Epetra, we will have the classes:
>
> class EpetraMatrix: public GenericMatrix
> class EpetraMatrixPattern: public GenericSparsityPattern
> class EpetraVector: public GenericVector
> class EpetraVectorPattern: public GenericSparsityPattern
>
> Other implementations can reuse the current SparsityPattern if they 
want to.
>
> In my opinion, the only ugly part is that
> GenericTensor::init(GenericSparsityPattern & pattern) won't really
> accept any subclass, but should have a type check and throw an
> exception. But we can't get around that with a virtual init
> function.

The same problem shows up if we want to add mult() to the
GenericMatrix interface (or any other function that involves
interaction between the two different GenericFoo classes).

So should we add type() as a method to all GenericFoo classes?

If the GenericFoo classes should be extendable by a user (who is not
allowed to edit GenericFoo), then type() could return a unique uint
(not enum) for each backend (uBlas = 1, PETSc = 2, Epetra = 3). Then a
user can add new backends 4, 5, etc.

> And at last there's still the parallellity troll waiting, probably
> requiring some more changes. But I think the distribution pattern can
> be merged nicely into the sparsity pattern similar to the Petra
> design.

ok.

/Anders