dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

Ola Skavhaug wrote:
> 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.

Yes, sounds good.

Although it won't do anything for efficiency for the current
implementation. The insert function is inlined and we call it by doing

  for (uint i = 0; i < dim0; ++i)
    for (uint j = 0; j < dim1; ++j)
      sparsity_pattern.insert( (ufc.macro_dofs[0])[i], 
(ufc.macro_dofs[1])[j] );

I suggest naming the block insert just "insert" and let it replace the
current insert. A small change will be needed also in
SparsityPatternBuilder to use the new interface.

/Anders


>>> 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