<div class="gmail_quote">On Tue, Mar 15, 2011 at 21:51, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com">knepley@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":2ih">Really? That seems perverse. I have to build some global PC matrix, with pieces I do not even have. How is that going to happen? Is<div>this really how we want to handle it?</div></div></blockquote><div><br>
</div><div>The alternatives don't compose properly, we'd need a whole new interface for disassembling solvers. Currently MatGetSubMatrix() is our way of taking things apart. If each "physics" is maintained separately, then you can use MatGetLocalSubMatrix(), see snes ex28.c, to decompose the global problem so that each physics module is stand-alone and has no global knowledge. It will also remain modular if you do splits inside of multigrid or multigrid inside of splits.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":2ih"><div> Also, I really need this to work now.</div></div></blockquote><div><br></div><div>It should work now.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":2ih"><div> So baring some other idea, I am going to put something in</div>
<div>PETSc that lets me set this operator during the SNES loop.</div></div></blockquote></div><br><div>On the first SNES iteration, the KSP has not been set up yet.</div>