On Mar 15, 2011, at 5:36 PM, Jed Brown wrote: > On Tue, Mar 15, 2011 at 23:28, Barry Smith <bsmith at mcs.anl.gov> wrote: > I'd like the flow control and ability to "do things" on inner blocks to be > the same regardless of the matrix class being used. I don't want suddenly > much more to code with or better functionality if you've chose one matrix > class over another (maybe much better speed but that is a different > question). So that's why I don't want it hardwired to MatNest > > It's not a matter of hardwiring it to MatNest, rather making the Mat that > comes out of MatGetSubMatrix() hold information about whether it has been > modified.
MatGetSubMatrix_MPIAIJ() can know that the requested portion of the matrix has not been changed and hence not actually get the matrix again and not update the state of the gotten matrix. > If you use AIJ, then you have necessarily reassembled the entire thing even > though part of it might be constant. It sounds like you're asking for an > external way to promise solvers that part of a matrix didn't change. I'd > rather let the solver check whether the matrix changed according to an > existing established API and leave the Mat responsible for saying when things > change. Agreed. I'm not asking for an EXTERNAL "way to promise solvers that part of a matrix didn't change" I'm just asking that all matrix classes be able to propagate this information NOT just MatNest(). > Seems more robust and could be used in many other places (for example, TS > could always think of the problem as nonlinear transient, but have operators > that happen to be linear time-independent only be factored once). > > An inexact method where the matrix is changing, but you want to delay setup > anyway is a different matter and seems to need to go into the solver.
