2007/7/24, Garth N. Wells <g.n.wells@xxxxxxxxxx>:
Martin Sandve Alnæs wrote:
As I understand it, "Matrix" is just a convenience class for users who
don't care about the underlying format. It should never be used at the
library level (because it ties the library to one format for each
compilation of the library), and can be ignored by anybody who
actually cares about which library they'll use.
I would say that it is more than just a convenience class - it's more
like the default linear algebra backend. Part of the idea is to tie the
library to one format in order to guarantee that various objects are
compatible with each other.
This doesn't sound like what Anders told me. Its the very idea of
"tying" the library compile-time to a single backend that I don't
like. As long as the rest of the library depends on GenericMatrix and
not Matrix, I'm happy. In that case, Matrix is a nice user-side
feature to keep user code portable.
A possibility would be to make objects like
Function templated, at the cost of increased complexity.
I don't see where Function enters this?
assemble(A, ...);
For the assembling this is fine, but the initialization before the
assembly may not be general enough:
If a dolfin::SparsityPattern is built inside dolfin::assemble(...) for
any matrix type, then a conversion between sparsity pattern structures
may be needed, possibly ~doubling the cost of the initialization
stage. Of course, this is not really important unless the application
has sparsity patterns that change often. However, if the Assembler is
supposed to keep a cache of initialized patterns, this grows tricky.
How are Epetra matrices initialised? Is it just a case of the number of
non-zeroes per row?
A bit simplified, yes that's one possible way. But the most general is
by using an Epetra_CrsGraph, which is a combined sparsity pattern and
a parallel distribution pattern. The parallel distribution pattern for
a vector is an Epetra_Map, and a crsgraph/matrix can have one or two
of these (rowmap, colmap).
Here's one of the crsgraph constructors:
//! Epetra_CrsGraph constuctor with variable number of indices per row.
/*! Creates a Epetra_CrsGraph object and allocates storage.
\param CV - (In) A Epetra_DataAccess enumerated type set to Copy or View.
\param RowMap - (In) An Epetra_BlockMap (or Epetra_Map or
Epetra_LocalMap) listing the rows that this
processor will contribute to.
\param ColMap - (In) An Epetra_BlockMap (or Epetra_Map or
Epetra_LocalMap) listing the columns that this
processor will contribute to.
\param NumIndicesPerRow - (In) An integer array of length NumMyRows
such that NumIndicesPerRow[i] indicates the (approximate if
StaticProfile=false) number of entries in the ith row.
\param StaticProfile - (In) Optional argument that indicates
whether or not NumIndicesPerRow should be interpreted as an exact
count of nonzeros, or should be used as an approximation.
By default this value is false, allowing the profile to be determined
dynamically. If the user sets it to true, then the memory
allocation for the Epetra_CrsGraph object will be done in one large
block, saving on memory fragmentation and generally improving the
performance of matrix multiplication and solve kernels.
*/
Epetra_CrsGraph(Epetra_DataAccess CV, const Epetra_BlockMap& RowMap,
const Epetra_BlockMap& ColMap, const int* NumIndicesPerRow, bool
StaticProfile = false);
martin
_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/mailman/listinfo/dolfin-dev
