dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Fri, May 22, 2009 at 09:01:25AM +0100, Garth N. Wells wrote:
> 
> 
> Anders Logg wrote:
> > On Fri, May 22, 2009 at 08:10:11AM +0100, Garth N. Wells wrote:
> >>
> >> Anders Logg wrote:
> >>> 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?
> >>>
> >> This might be what you want.
> >>
> >> http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatSeqAIJSetColumnIndices.html#MatSeqAIJSetColumnIndices
> >>
> >> Garth
> > 
> > Looks like these might be more interesting (can't find SetColumnIndices
> > for MPI matrix):
> > 
> > http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatSeqAIJSetPreallocationCSR.html
> > http://www.mcs.anl.gov/petsc/petsc-as/snapshots/petsc-current/docs/manualpages/Mat/MatMPIAIJSetPreallocationCSR.html
> >
> 
> These look too low level to me. They look appropriate for creating a 
> PETSc matrix from data underlying a CSR matrix (using what is returned 
> by GenericMatrix::data().

Perhaps. But it would be fairly easy to add the required data to
SparsityPattern so I might try to see if it improves performance.

It's not necessarily a low-level format. It's just that PETSc uses
low-level data structures for describing the sparsity pattern. It
might has well have been std::vector<std::map<uint, uint> >.

But do we agree that we design GenericSparsityPattern after what PETSc
needs and let the Epetra backend use a dynamic cast and give an error
for all the functions it does not implement?

-- 
Anders

Attachment: signature.asc
Description: Digital signature