The need for computation reuse (between J and J_pre, for example) might require a change in the SNES callback model.<div>Right now each call -- FormFunction, FormJacobian -- is stateless.  It takes a Vec X and computes the corresponding quantities -- residual, J, J_pre -- solely from X.  Any callback that  wanted to reuse any other callback's computation would have to be able to make sure the reuse is safe: am I being called with the same X as this previous callback that already precomputed a bunch of stuff for me?  This is only possible with a costly, collective (and imprecise) vector comparison, or a fragile state tracker within X.  If this is unacceptable, the callbacks must carry (and share) a state, and, thus, become objects.</div>

<div><br></div><div>That's probably undesirable within the basic SNES callback model, but may be natural within the DM-based callback model: a SNES sets its DM's Vec X and calls DMFunction, DMJacobian without any argument -- those calls pull out X and compute whatever they need, including some common data for others (e.g., PC DM) to reuse.  A new call to DMSetVec() will reset these common data structures.  This way the DM can also be viewed as a "factory".</div>

<div><br></div><div>This would probably make my interaction with libMesh a bit easier, but isn't strictly necessary.  Still, it would be good to know any thoughts on this.</div><div><br></div><div>Dmitry.<br><br><div class="gmail_quote">

On Sun, Feb 12, 2012 at 10:32 AM, 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">

<br><br><div class="gmail_quote"><div><div class="h5">On Sat, Feb 11, 2012 at 8:36 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 Sat, Feb 11, 2012 at 08:32, 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>This sounds fine to me, but what's the API for doing this? You want to do KSPSetDM() and PCSetDM(), </div><div>so that the user has to explicitly pull out the PC to set its DM?</div></blockquote></div><br></div>


<div>The PC *always* owns both matrices anyway.</div></blockquote><div><br></div></div></div><div>I think there is a rather natural API for handling DM grouping, code reuse and dealing with the issue of single matrix per DM:</div>

<div>
DM should support DMGetKSPDM(), DMGetPCDM() -- similar to DMDAGetCoordinateDA() --  each of which will compute the correct matrix. These calls can return the original DM (or PETSC_NULL) by default.  SNES will pull out the KSP DM out to set it on the KSP, KSP will do the same for the PC, etc. DM already has Vec x, so all of the DMs can share x and compute their respective matrices at the same x and reuse whatever computation is reusable.  That's up to the implementation, though.</div>

<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Dmitry.</div></font></span></div><br>
</blockquote></div><br></div>