<div class="gmail_quote">On Sun, Aug 14, 2011 at 17:48, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.</blockquote>
<div><br></div><div>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</div>
<div><br></div><div>* True residuals for GMRES</div><div><br></div><div>* Estimated eigenvalues or singular values</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
   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 :-).</blockquote></div>
<br><div>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.</div>