<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 4:05 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov">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 class="im"><div class="gmail_quote">On Fri, Feb 10, 2012 at 15:59, Matthew Knepley <span dir="ltr"><<a href="mailto:knepley@gmail.com" target="_blank">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>This makes no sense to me unless the two matrices being returned have different sparsity patterns, and we have no</div><div>good way for specifying that, or even a good rationale for doing it.</div></blockquote></div>


<br></div><div>Preconditioning with a STAR stencil is often pretty good.</div><div><br></div><div>Dmitry is suggesting specifying it by having two "slots" in which we can request a matrix.</div><div><br></div><div>

DMSetMatrixPreallocateOnly(), DMSetMatrixType(), and perhaps a couple others would need two arguments so the two matrices can be addressed separately.</div>
<div><br></div><div>It's not clear to me that two is always the right number of ways to distinguish matrices.</div></blockquote><div> </div><div>Well, two is the number that's used in KSP and SNES. </div><div><br>

</div><div>With the current API SNES actually uses the same matrix for the Jacobian and preconditioner, if the matrix is obtained from a DM, which is limiting.  It is natural to have a "geometric" backend (e.g., libMesh or MOOSE) interact with the algebraic objects (PETSc's SNES, KSP) through the DM as much as possible, since the DM (its impl, rather) carries all of the necessary mesh and discretization information in one place. Yet, currently this interaction is limited as compared to the "bare" SNES/KSP interface, in part because of the one matrix limitation.  </div>

<div><br></div><div>Dmitry.</div></div><br>