[petsc-dev] Monitor changes

[Jed Brown]

On Sun, Aug 14, 2011 at 17:48, Barry Smith <bsmith at mcs.anl.gov> wrote:

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


Yeah, I can understand the rationale for this, I'm just concerned that it
would become uglier, but for most fields, it's a cosmetic distinction. Let's
decide based on the more complicated situations. How would you handle the
AMS client wanting

* True residuals for GMRES

* Estimated eigenvalues or singular values


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


I don't think it's the eschewing files that would be the big win. Just using
a language with closures would get you most of the way there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110814/2d41c0d8/attachment.html>