<div class="gmail_quote">On Tue, Mar 15, 2011 at 23:28, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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</blockquote>
<div><br></div><div>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. 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. 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).</div>
<div><br></div><div>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.</div></div>