Barry, David and I are interested in this. At KAUST, we are starting a joint project with IBM in 'Computational Steering and Visualization'. It will be good to reassess this code under the current requirements.
Thanks, Dinesh Barry Smith said the following on 2/24/10 11:26 PM: > > I have located the tarball for the Alice Memory Snooper code (AMS). > If anybody would like a copy of it to look at, send me an email. The > code is ten years old and its makefile system is out of date and would > need minor working to get things compiled. This does not include any > PETSc code or interface code specific to PETSc (that can be found in > very old PETSc tarballs if anyone is interested). > > How it works. You register blocks of memory and their sizes in your > program via an API with names and then "lock" and "unlock" read and > write access to those registered blocks via the API. There can be a > hierarchy of these registered blocks. Then other programs can via > another API, access these blocks of memory and read and write values to > them. It is implemented by having the original process spawn a thread > that waits for socket connects and processing the requests, subject to > locks that may be turned on and off in the original program. It can be > built so that original program is a parallel program running with MPI. > It provides a way for someone to "find out what the heck is actually > going on" in a long running program without resorting to printfs and > other nonsense. It is pretty well documented. > > It is a pretty sweet model and piece of code but would require a small > amount of hacking to get running. If anyone wants to hack at it we could > set up a repository. > > Barry > > When we developed it, ORNL had a similar but much more limited piece > of software that ran on top of PVM called CUMULUS, we were told that ANL > shouldn't spend any money on AMS because it "competed" with CUMULUS. > Hence I dropped it, that was over 10 years ago so I don't see that as an > issue any more.
