<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 4:28 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="gmail_quote"><div class="im">On Fri, Feb 10, 2012 at 16:13, 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">


<div>Well, two is the number that's used in KSP and SNES. </div></blockquote><div><br></div></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></blockquote><div> </div><div>The mass matrix (plus a lumped mass matrix to build the preconditioner) for an "explicit" integrator is the very example I had in mind. Time integrators, however, have a different API from SNES and KSP.  Maybe multiple DMs would be appropriate in that situation (if necessary, sharing the backend mesh or whatever other data structures for efficiency) -- a DM for each explicit and implicit stage.  Yet, the SNES/KSP for each stage requires two matrices, so it would be natural for DM to reflect that.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im">
<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></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></blockquote><div>

<br></div><div>I would also vote for a more transparent name for that option -- "mf_operator" seems rather obscure. </div><div><br></div><div>Dmitry.</div></div><br>