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>
