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
signature.asc
Description: Digital signature
_______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
