On Sun, Aug 14, 2011 at 19:16, Barry Smith <bsmith at mcs.anl.gov> wrote:
> 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 .... > 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. > > 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. > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110814/ecb70af1/attachment.html>
