## Re: [Libmesh-devel] EpetraMatrix sparsity pattern

 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 20:43:46 ```Ok - I just committed the sparsity pattern stuff... and now you can use Trilinos to solve Example3! I know there's still a lot of work (and cleanup) left to do... but it is technically working. One thing I know for sure is that it's probably leaking memory like a bitch ;-) I'll deal with that next week though ;-) Thanks for all the help everyone! Derek On Aug 22, 2008, at 2:09 PM, Benjamin Kirk wrote: > Should the trilinos list get queried? Is that a bug?? > > >> What do you think Ben? Shouldn't be too hard right? After a bit >> of looking >> around it appears that the dof_map can generate the full sparsity >> pattern >> which shouldn't be too hard to translate into the CrsGraph that >> Epetra wants. > > Right. You need to overload the > SparseMatrix::need_full_sparsity_pattern() > to return true, and then implement the > SparseMatrix::update_sparsity_pattern() member (like is done in the > LaspackMatrix). > > The idea is as follows... > > (1) The DofMap constructs the graph of the sparse matrix when > assigning the > degrees of freedom, but it does not need to keep this around > > (2) for formats like petsc, the graph is not needed, only an > accurate (or > bounding) count on the number of nonzeros per row. > > (3) this thing is about the size of the local matrix, so once it is > constructed and no longer needed it can be thrown away. However, > before > throwing it away, the DofMap gives the SparseMatrix'es the option to > use it. > > In any case, see what you can do with it. It is really simple, the > SparsityPattern::Graph is simply a vector-of-vectors, with > > sparsity_pattern.size() = n_local_rows > sparsity_pattern[row].size() = # of nonzeros on 'row' > sparsity_pattern[row][i] = col > (where row,col is the global matrix index for the ith nonzero entry > on this > row.) > > -Ben > > ```

 [Libmesh-devel] EpetraMatrix sparsity pattern From: Benjamin Kirk - 2008-08-21 16:58:29 ```Derek, I just checked in a change which should construct the map properly for a sparse matrix in trilinos. Now, I remember thinking this was gonna be harder than what I just did, so maybe I missed something? In any case, check it out... -Ben ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 13:35:00 ```Sweet! I'll take a look. I had to do presentations all day yesterday... but I'm back on working on this today. Derek On Aug 21, 2008, at 10:58 AM, Benjamin Kirk wrote: > Derek, > > I just checked in a change which should construct the map properly > for a > sparse matrix in trilinos. Now, I remember thinking this was gonna be > harder than what I just did, so maybe I missed something? > > In any case, check it out... > > -Ben > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmesh-devel mailing list > Libmesh-devel@... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 19:57:53 Attachments: Message as HTML ```With the commit I just made.... Trilinos support for solving linear problems is basically there.... there is just one piece missing.... The piece that is missing has to do with the way Epetra_FECrsMatrix works with SumIntoGlobalValues. It turns out that if there hasn't been a value _INSERTED_ into that position before you try to sum into it.... it will ignore the summed value! I ran into this about a year ago when I was doing my own application. What I did back then was just do an InsertGlobalValues() of all zeroes for everywhere that I needed to sum in. In reality, I think what needs to be done is an Epetra_CrsGraph() needs to get filled out with the exact non-zero sparsity pattern. What do you think Ben? Shouldn't be too hard right? After a bit of looking around it appears that the dof_map can generate the full sparsity pattern which shouldn't be too hard to translate into the CrsGraph that Epetra wants. I'm going to work on this a bit for the next hour or so, but if you can get it done quicker than I am... feel free! Derek On Fri, Aug 22, 2008 at 7:35 AM, Derek Gaston wrote: > Sweet! I'll take a look. > > I had to do presentations all day yesterday... but I'm back on working on > this today. > > Derek > > > On Aug 21, 2008, at 10:58 AM, Benjamin Kirk wrote: > > Derek, >> >> I just checked in a change which should construct the map properly for a >> sparse matrix in trilinos. Now, I remember thinking this was gonna be >> harder than what I just did, so maybe I missed something? >> >> In any case, check it out... >> >> -Ben >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Libmesh-devel mailing list >> Libmesh-devel@... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> > > ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Benjamin Kirk - 2008-08-22 20:09:41 ```Should the trilinos list get queried? Is that a bug?? > What do you think Ben? Shouldn't be too hard right? After a bit of looking > around it appears that the dof_map can generate the full sparsity pattern > which shouldn't be too hard to translate into the CrsGraph that Epetra wants. Right. You need to overload the SparseMatrix::need_full_sparsity_pattern() to return true, and then implement the SparseMatrix::update_sparsity_pattern() member (like is done in the LaspackMatrix). The idea is as follows... (1) The DofMap constructs the graph of the sparse matrix when assigning the degrees of freedom, but it does not need to keep this around (2) for formats like petsc, the graph is not needed, only an accurate (or bounding) count on the number of nonzeros per row. (3) this thing is about the size of the local matrix, so once it is constructed and no longer needed it can be thrown away. However, before throwing it away, the DofMap gives the SparseMatrix'es the option to use it. In any case, see what you can do with it. It is really simple, the SparsityPattern::Graph is simply a vector-of-vectors, with sparsity_pattern.size() = n_local_rows sparsity_pattern[row].size() = # of nonzeros on 'row' sparsity_pattern[row][i] = col (where row,col is the global matrix index for the ith nonzero entry on this row.) -Ben ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 20:13:17 ```Great, thanks for the info... I am actually pretty close to having this done... Derek On Aug 22, 2008, at 2:09 PM, Benjamin Kirk wrote: > Should the trilinos list get queried? Is that a bug?? > > >> What do you think Ben? Shouldn't be too hard right? After a bit >> of looking >> around it appears that the dof_map can generate the full sparsity >> pattern >> which shouldn't be too hard to translate into the CrsGraph that >> Epetra wants. > > Right. You need to overload the > SparseMatrix::need_full_sparsity_pattern() > to return true, and then implement the > SparseMatrix::update_sparsity_pattern() member (like is done in the > LaspackMatrix). > > The idea is as follows... > > (1) The DofMap constructs the graph of the sparse matrix when > assigning the > degrees of freedom, but it does not need to keep this around > > (2) for formats like petsc, the graph is not needed, only an > accurate (or > bounding) count on the number of nonzeros per row. > > (3) this thing is about the size of the local matrix, so once it is > constructed and no longer needed it can be thrown away. However, > before > throwing it away, the DofMap gives the SparseMatrix'es the option to > use it. > > In any case, see what you can do with it. It is really simple, the > SparsityPattern::Graph is simply a vector-of-vectors, with > > sparsity_pattern.size() = n_local_rows > sparsity_pattern[row].size() = # of nonzeros on 'row' > sparsity_pattern[row][i] = col > (where row,col is the global matrix index for the ith nonzero entry > on this > row.) > > -Ben > > ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 20:26:15 ```Ok - one thing I'm confused about is what should go into update_sparsity_pattern and what should go into init().... Will init() ever be called without calling update_sparsity_pattern() first? If not then I'm going to put both the Epetra_Map and Epetra_CrsGraph creation into update_sparsity_pattern() and only the creation of the Epetra_FECrsVector into init(). And update_sparsity_pattern() should call init() right? Derek On Aug 22, 2008, at 2:09 PM, Benjamin Kirk wrote: > Should the trilinos list get queried? Is that a bug?? > > >> What do you think Ben? Shouldn't be too hard right? After a bit >> of looking >> around it appears that the dof_map can generate the full sparsity >> pattern >> which shouldn't be too hard to translate into the CrsGraph that >> Epetra wants. > > Right. You need to overload the > SparseMatrix::need_full_sparsity_pattern() > to return true, and then implement the > SparseMatrix::update_sparsity_pattern() member (like is done in the > LaspackMatrix). > > The idea is as follows... > > (1) The DofMap constructs the graph of the sparse matrix when > assigning the > degrees of freedom, but it does not need to keep this around > > (2) for formats like petsc, the graph is not needed, only an > accurate (or > bounding) count on the number of nonzeros per row. > > (3) this thing is about the size of the local matrix, so once it is > constructed and no longer needed it can be thrown away. However, > before > throwing it away, the DofMap gives the SparseMatrix'es the option to > use it. > > In any case, see what you can do with it. It is really simple, the > SparsityPattern::Graph is simply a vector-of-vectors, with > > sparsity_pattern.size() = n_local_rows > sparsity_pattern[row].size() = # of nonzeros on 'row' > sparsity_pattern[row][i] = col > (where row,col is the global matrix index for the ith nonzero entry > on this > row.) > > -Ben > > ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-22 20:43:46 ```Ok - I just committed the sparsity pattern stuff... and now you can use Trilinos to solve Example3! I know there's still a lot of work (and cleanup) left to do... but it is technically working. One thing I know for sure is that it's probably leaking memory like a bitch ;-) I'll deal with that next week though ;-) Thanks for all the help everyone! Derek On Aug 22, 2008, at 2:09 PM, Benjamin Kirk wrote: > Should the trilinos list get queried? Is that a bug?? > > >> What do you think Ben? Shouldn't be too hard right? After a bit >> of looking >> around it appears that the dof_map can generate the full sparsity >> pattern >> which shouldn't be too hard to translate into the CrsGraph that >> Epetra wants. > > Right. You need to overload the > SparseMatrix::need_full_sparsity_pattern() > to return true, and then implement the > SparseMatrix::update_sparsity_pattern() member (like is done in the > LaspackMatrix). > > The idea is as follows... > > (1) The DofMap constructs the graph of the sparse matrix when > assigning the > degrees of freedom, but it does not need to keep this around > > (2) for formats like petsc, the graph is not needed, only an > accurate (or > bounding) count on the number of nonzeros per row. > > (3) this thing is about the size of the local matrix, so once it is > constructed and no longer needed it can be thrown away. However, > before > throwing it away, the DofMap gives the SparseMatrix'es the option to > use it. > > In any case, see what you can do with it. It is really simple, the > SparsityPattern::Graph is simply a vector-of-vectors, with > > sparsity_pattern.size() = n_local_rows > sparsity_pattern[row].size() = # of nonzeros on 'row' > sparsity_pattern[row][i] = col > (where row,col is the global matrix index for the ith nonzero entry > on this > row.) > > -Ben > > ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Benjamin Kirk - 2008-08-22 21:03:23 ```> I know there's still a lot of work (and cleanup) left to do... but it > is technically working. One thing I know for sure is that it's > probably leaking memory like a bitch ;-) I'll deal with that next > week though ;-) ex4 on two processors doesn't work yet! ;-) > Thanks for all the help No problem. Glad to see this capability coming together! -Ben ```
 Re: [Libmesh-devel] EpetraMatrix sparsity pattern From: Derek Gaston - 2008-08-26 18:48:53 Attachments: Message as HTML ```On Fri, Aug 22, 2008 at 3:03 PM, Benjamin Kirk wrote: > ex4 on two processors doesn't work yet! ;-) > Ok - I've committed a couple more fixes, and it appears that everything is working well now. The only thing left is adaptivity, but it might be a bit before I can look at that. I'm going to go through and do some cleanup and get rid of some of the most blatant memory leakages. We're also working on the NOX interface for NonlinearSolver... we're about 50% done. Hopefully we'll get that hammered out in the next day or so. Derek ```