[petsc-dev] Monitor changes

[Barry Smith]

On Aug 14, 2011, at 6:12 PM, Jed Brown wrote:

> 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

    In the current model we simply change some KSP options so the next time it runs it computes those additional things. So this is no different then putting into the code, for example, if timestep == 29 KSPSetComputeSingularValues().  Note that this does change the flow of the running code.

    In an alternative model, much more thready, it would trigger additional threads to do this "other stuff" while leaving the main thread running along as it does now. The nice thing about this model is the main code base doesn't need to know about all these cool new things that can be computed, the drawback is more sophisticated design of everything ....

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

  It's not the files that matter, it is the ability to write code that manipulates code rather than every code change being someone using an editor to touch source code directly.

   Barry