On Fri, Feb 10, 2012 at 4:28 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Fri, Feb 10, 2012 at 16:13, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote: > >> Well, two is the number that's used in KSP and SNES. >> > > DM can be used outside of KSP and SNES. > > 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). > 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. > >> >> 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. >> > > 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. > I would also vote for a more transparent name for that option -- "mf_operator" seems rather obscure. Dmitry. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20120210/2f022244/attachment.html>