dolfin team mailing list archive
-
dolfin team
-
Mailing list archive
-
Message #05551
About SparsityPattern
Ola and I did some thinking on the SparsityPattern vs Epetra_CRSGraph
issue, ie the case where you want the Assembler to use an external
class for building the sparsity pattern. I think we came up with a
nice solution, in fact it looks much like the GenericTensor::create()
function we added earlier (as well as the ufc::form::create_*
functions).
Basically, a GenericTensor knows the type of the
GenericSparsityPattern it expects in init(pattern). Thus we can do
this:
in application:
A = Matrix()
assemble(A, ...)
in assemble:
pattern = A.createPattern()
initPattern(pattern, ...)
A.init(pattern)
...
with
class GenericSparsityPattern
{
virtual void insertBlock(rows, cols, ...) = 0;
...
}
class GenericTensor
{
GenericSparsityPattern * createPattern() const = 0;
// similar to what we added earlier:
GenericTensor * create() const = 0;
}
Then, for Epetra, we will have the classes:
class EpetraMatrix: public GenericMatrix
class EpetraMatrixPattern: public GenericSparsityPattern
class EpetraVector: public GenericVector
class EpetraVectorPattern: public GenericSparsityPattern
Other implementations can reuse the current SparsityPattern if they want to.
In my opinion, the only ugly part is that
GenericTensor::init(GenericSparsityPattern & pattern) won't really
accept any subclass, but should have a type check and throw an
exception. But we can't get around that with a virtual init function.
And at last there's still the parallellity troll waiting, probably
requiring some more changes. But I think the distribution pattern can
be merged nicely into the sparsity pattern similar to the Petra
design.
--
Martin
Follow ups