On Aug 14, 2011, at 4:59 PM, Jed Brown wrote: > 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).
Agreed > 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. So you are willing to have the AMS buffer values that "often aren't valid any more" but you don't want PETSc to buffer those same values? We could certainly introduce the concept of "transient" values, but what would be their lifetimes? Would there be a mechanism for them to be "updated" automatically? Knowing how old they are? Why would the " logic would become more spread out", you would compute these values in the code that makes the most sense. I think, though I may be remembering wrong, there is a concept of calling a function on the publisher when updating the accessor with the latest memory values. This function would then compute the derived quantities you want using whatever the most current other values are. I'm guessing what you don't like is that there is still a memory location in the PETSc object (or somewhere in the heap) where the value "lives". Perhaps we could add support for that memory location to live in AMS memory space instead. The "compute the derived quantity function" would be PETSc code callback registered with the AMS. So I am not totally disagreeing with you, I just want to make sure what you want is needed before we go and grow all kinds of new code in a code base we are not familar with. Barry
