← Back to team overview

dolfin team mailing list archive

About SparsityPattern

 

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, ...)
  A.init(pattern)
  ...

with

class GenericSparsityPattern
{
  virtual void insertBlock(rows, cols, ...)  = 0;
  ...
}

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.

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.

--
Martin


Follow ups