<div class="gmail_quote">On Sun, Aug 14, 2011 at 19:16, 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;">
<div id=":16d">  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.<br>

<br>
    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 ....<br>
</div></blockquote><div><br></div><div>Yeah, this is the distinction I was thinking of. If the AMS client (or some other thread) was going to go solve the reduced eigenvalue problem, this might suggest a more AMSy approach instead of up-front computing plus a dumb viewer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div id=":16d"><div class="im"> </div>  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.<br>
</div></blockquote></div><br><div>And then PETSc was reimplemented in PLT Racket and never seen or heard from again, although graduate students still tell legends of the fantastic things that it could do.</div>