Re: [Libmesh-devel] Truly Matrix Free Nonlinear Solves

 Re: [Libmesh-devel] Truly Matrix Free Nonlinear Solves From: Roy Stogner - 2009-06-29 22:42:51 ```On Mon, 29 Jun 2009, John Peterson wrote: > 2.) Could you hack up a new SparseMatrix implementation or some kind > of shell matrix which does nothing when told to initialize itself and > throws errors when it's told to do something it doesn't know how to > do? This is the best idea I've heard so far. You can perfectly reflect the desired "I've still got an implicit system but the Jacobian is something I never calculate explicitly" behavior by creating a Jacobian object that never gets calculated explicitly. --- Roy ```

 [Libmesh-devel] Truly Matrix Free Nonlinear Solves From: Derek Gaston - 2009-06-29 20:28:30 ```As you guys are no doubt aware... we do everything matrix / jacobian free. Unfortunately... even though we don't fill it... the memory for a sparse jacobian gets set aside in ImplicitSystem (check out ImplicitSystem::init_data() and init_matrices() ). What can we do about this? It seems like the assumption (rightly so at the time) was made that every Implicit solve will need a system matrix.... and now we've found a case where that isn't true. We could, of course, derive a new tree of Systems from ExplicitSystem that behaves similarly to the (Nonlinear)ImplicitSystem tree... but that feels like a bad duplication for something that really comes down to a small change in behavior. The other option seems to be something along the lines of setting a bool in ImplicitSystem and putting ifs all over the places to do the correct thing. This gets a bit tricky though because those ifs have to propogate all the way out to the leaves of the tree (for instance the solve() methods for both linear and nonlinear solvers take _references_ to SparseMatrixs.... which means we'll have to do some work to make it possible to _not_ have a matrix). Any ideas here? Obviously I'm asking this question because this is now starting to be a problem. We're looking at solving systems of 50 or more variables.... and allocating a sparse matrix that we never use is pretty sloppy. Derek ```
 Re: [Libmesh-devel] Truly Matrix Free Nonlinear Solves From: Kirk, Benjamin (JSC-EG311) - 2009-06-29 20:32:31 ```> The other option seems to be something along the lines of setting a > bool in ImplicitSystem and putting ifs all over the places to do the > correct thing. This gets a bit tricky though because those ifs have > to propogate all the way out to the leaves of the tree (for instance > the solve() methods for both linear and nonlinear solvers take > _references_ to SparseMatrixs.... which means we'll have to do some > work to make it possible to _not_ have a matrix). Would it be possible to put the system matrix in an AutoPtr that can be NULLED? The references would obviously need to get replaced with pointers... The other option would be to just never initialize the sparse matrix, right? -Ben ```
 Re: [Libmesh-devel] Truly Matrix Free Nonlinear Solves From: John Peterson - 2009-06-29 21:44:57 ```On Mon, Jun 29, 2009 at 3:07 PM, Derek Gaston wrote: > We could, of course, derive a new tree > of Systems from ExplicitSystem that behaves similarly to the > (Nonlinear)ImplicitSystem tree... but that feels like a bad > duplication for something that really comes down to a small change in > behavior. 1.) Instead of doing a duplicate tree, could you just redo your current tree to inherit from ExplicitSystem instead, and then manage when and where a SparseMatrix is needed in your framework code? 2.) Could you hack up a new SparseMatrix implementation or some kind of shell matrix which does nothing when told to initialize itself and throws errors when it's told to do something it doesn't know how to do? -- John ```
 Re: [Libmesh-devel] Truly Matrix Free Nonlinear Solves From: Roy Stogner - 2009-06-29 22:42:51 ```On Mon, 29 Jun 2009, John Peterson wrote: > 2.) Could you hack up a new SparseMatrix implementation or some kind > of shell matrix which does nothing when told to initialize itself and > throws errors when it's told to do something it doesn't know how to > do? This is the best idea I've heard so far. You can perfectly reflect the desired "I've still got an implicit system but the Jacobian is something I never calculate explicitly" behavior by creating a Jacobian object that never gets calculated explicitly. --- Roy ```