Martin Sandve Alnæs wrote: > 2007/7/24, Garth N. Wells <[EMAIL PROTECTED]>: >> 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? >
A Function requires a vector to store the dofs. This is currently a Vector, so it would have to be possible to specify the type of vector. With the current design, it's not enough to just make the underlying pointer a GenericVector. Garth > >>>> 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 > [email protected] > http://www.fenics.org/mailman/listinfo/dolfin-dev > _______________________________________________ DOLFIN-dev mailing list [email protected] http://www.fenics.org/mailman/listinfo/dolfin-dev
