dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

I'm looking at how to extend GenericSparsityPattern for parallel
assembly.

Currently, the interface allows the number of nonzeros per row to be
retrieved when initializing a matrix (through the common interface).

For PETSc, the interface needs to be extended to include both the
number of nonzeros in the diagonal block and offdiagonal blocks for
each row. This is already in the subclass SparsityPattern and a cast
is used in PETScMatrix to convert the GenericSparsityPattern to a
SparsityPattern so the offdiagonal nonzeros may be retrieved.

For Epetra, we have a subclass EpetraSparsityPattern and also a cast
in EpetraMatrix.

So, what would be a sensible way to design/implement the different
sparsity patterns? One option could be to extend
GenericSparsityPattern with the stuff needed for PETSc, and just have
those functions return an error for Epetra. There would then be a
single cast (in EpetraMatrix) and all backends except Epetra would use
the SparsityPattern implementation. If so, I can go ahead and make the
required changes so it works with PETSc. Epetra should work as is I
guess, assuming Epetra_FECrsGraph& does the right thing.

On a side note, we build much more information in SparsityPattern than
we actually need for PETSc. We know all the nonzero columns but just
count the total number and throw away the more fine-grained
information. Is there a way to pass this on to PETSc and have PETSc
use it?

-- 
Anders

Attachment: signature.asc
Description: Digital signature