[petsc-dev] Monitor changes

[Barry Smith]

On Aug 14, 2011, at 5:31 PM, Jed Brown wrote:

> On Sun, Aug 14, 2011 at 17:16, Barry Smith <bsmith at mcs.anl.gov> wrote:
>  So you are willing to have the AMS buffer values that "often aren't valid any more" but you don't want PETSc to buffer those same values?  We could certainly introduce the concept of "transient" values, but what would be their lifetimes? Would there be a mechanism for them to be "updated" automatically? Knowing how old they are?
> 
> Can't AMS do some sort of reference counting on the client handle so it could know when the last reference was dropped?

   Of course, that is not my point. 

> PETSc could also buffer those values, I just don't want them to go into the SNES directly (i.e. as programmer-visible fields in _p_SNES) because it's clutter that's too easy to misuse and because it requires a recompile just to have a "viewer" provide an extra computed quantity. I think the minimal change necessary to provide a new computed quantity for viewing/monitoring should be one line in the view routine, not editing data structures.
> 
> Using callbacks for every computed quantity also sounds like more complexity than an AMS call that buffers the field.

   My concern is that someone publishes a computed value at the beginning of the run; six hours of running later someone using the accessor to see that value but it no longer has any relevance to the running code. How does the person know this? With "regular" published memory they know they are seeing values directly in the publishers running code at that instant, with this all they are seeing is some value someone set a long time ago that is not part of the current running code. 

   Again I am not saying no, I am just concerned that it is isn't the right thing to do. After all if I just want to look at what SNESView said some time ago I might as well just dump it to a file and then later I can read that file, I am not getting a current snapshot. I am getting an old snapshot.  The idea with the memory snooper is you can get a current view of what is going on WITHOUT requiring the publisher program to call Views or whatever on a regular basis. This is why I argue the computation of the derived quantities should be under the control of the snooper (with with callbacks to PETSc code or in the snooper GUI) rather then dependent on the publisher program calling them at each time step, or solve or whatever.   Let's take a concrete example, say I wish to look at the ratio of the two norm of the current residual to the two norm of b. In your model the publisher code would need to at each iteration compute this ratio and call some AMS save transient value routine. With my model the GUI or the callback would compute it WHEN I the accessor wants it (and not at other times), not when the programmer of the publishing code decided to compute it.  You are right, there is a question of managing where the code that computes these things lives and is managed (if we had a decent code management system based on LLVM this wouldn't be a problem :-).


  Barry


   Barry