<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 12:11 AM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@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">


<div><div class="gmail_quote">On Fri, Feb 10, 2012 at 00:02, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@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">



Yes. And, by the way, preallocation for J and P could be different (e.g., mass matrix vs lumped mass matrix for projection problems).  As could be the preferred MatType.</blockquote></div><br></div><div>This is not easy to encode in a DM, the user should do the allocation in this case (maybe another hook is needed).</div>


</blockquote><div> </div><div>The DM is the user here, or a proxy for the user. DM actually has all of the mesh connectivity data necessary for preallocation, so doing it any other way would basically involve passing the DM implementation as the user context anyway.  It appears much more natural to have this as a DM method. Of course, it is always possible to create</div>

<div>new matrices and allocate differently during a call to SNESDMComputeJacobian, but then what is the purpose of DMGetMatrix? </div>
<div><br></div><div><br></div><div>I think returning two matrices is natural in the KSP context at any rate: we always want a matrix and an approximation</div><div>to it to form the preconditioner.  It's the same in the SNES context -- the Jacobian and an approximation.  </div>


<div>I'm we could add something like DMGetOperators(DM dm, MatType jtype, Mat *J, MatType ptype, Mat *P),</div><div>which mirrors the ultimate use of these matrices in KSPSetOperators.</div><div><br></div><div>Dmitry.</div>

</div><br>