[petsc-dev] Lagging the numerical factorization for one of the fields of fieldsplit preconditioner

[Barry Smith]

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.