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.
>
>
