[petsc-dev] DMGetMatrix --> DMGetMatrices?

[Barry Smith]

On Feb 17, 2012, at 10:12 PM, Dmitry Karpeev wrote:

> The need for computation reuse (between J and J_pre, for example) might require a change in the SNES callback model.
> 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.
> 
> 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".
> 
> This would probably make my interaction with libMesh a bit easier, but isn't strictly necessary.

    Tell us what is making your interactions with libMesh less easy. That is, tell us your problem, not your proposed solution to the problem, what specifically are you trying to do with libMesh and why is it less easy then you would like.

    Barry


  
>  Still, it would be good to know any thoughts on this.
> 
> Dmitry.
> 
> On Sun, Feb 12, 2012 at 10:32 AM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> 
> 
> On Sat, Feb 11, 2012 at 8:36 AM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> On Sat, Feb 11, 2012 at 08:32, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:
> This sounds fine to me, but what's the API for doing this? You want to do KSPSetDM() and PCSetDM(), 
> so that the user has to explicitly pull out the PC to set its DM?
> 
> The PC *always* owns both matrices anyway.
> 
> I think there is a rather natural API for handling DM grouping, code reuse and dealing with the issue of single matrix per DM:
> 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.
> 
> Dmitry.
> 
>