Anders Logg skrev den 09/10-2007 følgende: > Ola Skavhaug wrote: > >Hi, > > > >I'm working on implementing pycc::CRS as a direct sub class of > >dolfin::GenericMatrix, and need an abstract base class for sparsity > >patterns. > >For the moment, dolfin::SparsityPattern is not polymorphic, so I can't > >inherit > >from it. The best solution would perhaps be to have a > >GenericSparsityPattern > >defining the public interface for sparsity patterns, and then dolfin can > >implement dolfin::SparsityPattern as a concrete subclass, and in PyCC we > >can > >implement a pycc::CRSGraph as another subclass. > > Sounds good, but what is it that CRSGraph needs that SparsityPattern > does not already provide? The sparsity pattern is computed as a > > std::vector< std::set<int> > sparsity_pattern; > > which presumably should be enough to initialize a CRS matrix.
Sure, this is enough for CRS at the time being, but I generally expect different (distributed) sparse matrices to have different sparsity patterns. The opposite approach could lead to trouble, trying to put too much functionality into a single class, I fear. Either way, I suggest that we add a block insert method to the sparsity pattern interface for efficiency. > >Any ideas or future plans for implementing this? The benefit from this > >construction would be the possibility of using dolfin/ffc to assemble pdes > >in > >PyCC, such that we can throw our old matrix factories out the door. > > Just go ahead and implement it (if you need it, see above). Will do (not sure it is strictly needed for CRS, however. For Epetra matrices, I think my suggestion makes sense.) Ola > /Anders > > > >Ola > >_______________________________________________ > >DOLFIN-dev mailing list > >[email protected] > >http://www.fenics.org/mailman/listinfo/dolfin-dev _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
