[petsc-dev] Monitor changes

[Jed Brown]

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>