dolfin team mailing list archive

[Ola Skavhaug <skavhaug@xxxxxxxxx>]

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
> >DOLFIN-dev@xxxxxxxxxx
> >http://www.fenics.org/mailman/listinfo/dolfin-dev