<div class="gmail_quote">On Fri, Feb 10, 2012 at 16:13, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov">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">
<div>Well, two is the number that's used in KSP and SNES. </div></blockquote><div><br></div><div>DM can be used outside of KSP and SNES.</div><div><br></div><div>It may well make sense to have J and Jpre corresponding to the implicit part of an equation plus a "mass matrix" to be used for "explicit stages" in an IMEX method. That is three (or even four if the mass matrix needs a preconditioner) extracted from the same DM (in different solves).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>
</blockquote></div><br><div>I agree that it's clumsy that -snes_mf_operator is the only "nice" way to get matrix-free in some cases, and it only gives you one kind of matrix-free.</div>