[petsc-dev] Monitor changes

Jed Brown jedbrown at mcs.anl.gov
Sun Aug 14 16:59:57 CDT 2011


On Sun, Aug 14, 2011 at 15:10, Barry Smith <bsmith at mcs.anl.gov> wrote:

> On Aug 14, 2011, at 2:58 PM, Jed Brown wrote:
>
> > On Sun, Aug 14, 2011 at 13:11, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >   Yes, the publisher is required to insure that all memory references
> that they publish as fields remain around as long as the AMS memory exists.
> >
> > This is the problem.
>
>    "the" problem?  I don't see it as a problem at all :-)
>
>   You seem to want to have a neutral GUI backend that know's nothing about
> PETSc, it just transfers data and displays it. While those type do have
> their place I always envisioned also PETSc specific backends that presented
> the data so, for example, the GUI backend for SNES would know about things
> in SNES and could display computed quantities specific to SNES.  In
> addition, if there is a "computed" value you want transmitted it can be
> simply added to the PETSc object (or subclass) and then an AMS field made
> for it. You are perhaps trying to make the AMS model something it is not, it
> is called a memory snooper because that is what it is, otherwise we would
> need to change the name to Memory snooper and other random stuff :-).


I really don't care whether AMSAORS is involved, I'm just concerned about
having a GUI that receives information from the running program using more
than one protocol (because it would be more confusing to configure and
debug). I'd rather not make fields in SNES for every computed quantity
because they often aren't valid any more and the logic would become more
spread out. I'd also rather not duplicate the logic to compute these values.

To keep the design consistent, what about having AMS buffer computed values
so that a client GUI can have a consistent API to read-only
application-backed memory fields and computed values.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110814/11758b5e/attachment.html>


More information about the petsc-dev mailing list