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
