Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
Close
From: Derek Gaston <friedmud@gm...>  20080826 18:48:53
Attachments:
Message as HTML

On Fri, Aug 22, 2008 at 3:03 PM, Benjamin Kirk <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 
From: Benjamin Kirk <benjamin.kirk@na...>  20080821 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 
From: Derek Gaston <friedmud@gm...>  20080822 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://moblincontest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Libmeshdevel mailing list > Libmeshdevel@... > https://lists.sourceforge.net/lists/listinfo/libmeshdevel 
From: Derek Gaston <friedmud@gm...>  20080822 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 nonzero 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 <friedmud@...> 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://moblincontest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Libmeshdevel mailing list >> Libmeshdevel@... >> https://lists.sourceforge.net/lists/listinfo/libmeshdevel >> > > 
From: Benjamin Kirk <benjamin.kirk@na...>  20080822 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 vectorofvectors, 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 
From: Derek Gaston <friedmud@gm...>  20080822 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 vectorofvectors, 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 > > 
From: Derek Gaston <friedmud@gm...>  20080822 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 vectorofvectors, 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 > > 
From: Derek Gaston <friedmud@gm...>  20080822 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 vectorofvectors, 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 > > 
From: Benjamin Kirk <benjamin.kirk@na...>  20080822 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 
From: Derek Gaston <friedmud@gm...>  20080826 18:48:53
Attachments:
Message as HTML

On Fri, Aug 22, 2008 at 3:03 PM, Benjamin Kirk <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 