Martin's mail
Dear all,
as we discussed at the last computing meeting, the time has come to augment the currently existing analysis framework with a top layer that relieves us from the more tedious aspects of the job, such as worrying about event loops, manually loading a truckload of libraries, and so on. I summarized the reasoning in my presentation at the computing meeting,
http://www.phenix.bnl.gov/phenix/WWW/p/draft/purschke/compmtg11-oct-2000/
We heard few objections to the use of a subset of the existing pmonitor framework for the analysis of PRDF's, but it was also stated that the more immediate need is on the DST analysis side. After a lot of input from Irina, Dave, and Chris Pinkenburg, I'm happy to announce that a first version of such a top layer/framework is ready to be tried. It's called "pdst" and works in the same spirit as pmonitor (minus the online capabilities), just uses DST events instead of PRDF events in its event loop. This night it will be included in the rebuild, and the libraries should be available in the morning in the standard OFFLINE_MAIN installation. Just as pmonitor does for PRDF's, pdst will provide you with root commands which open a DST file, and lets you loop over a given number or all events in there. In the beginning a user-provided init routine gets called (where you typically book histograms, ntuples, open the DB, etc), and another routine gets called for each event which is read in from the DST. All in compiled code. Also, no longer a need to know in advance how many events are in a dst, and it's trivial to run through several DST's in a row. I think the best is the alredy advertised simplification of the shared library management - your code links with libpdst.so and doesn't need to bother with any but your very own additional shared libs. pdst knows about all needed libraries already. While pmonitor calls a user routine > int process_event(Event *e) for each PRDF event, pdst calls a user routine > int process_event (PHCompositeNode *node) the node representing a DST node tree read in from the root file. pmonitor calls the user-provided init routine "int pinit()", in pdst this is "int dinit()". This is done on purpose; in this way DST and PRDF-analysis projects can potentially coexist without name clashes. Each pmonitor root-level command used in a non-online setting ( pstatus, pfileopen, prun, pclose ) has a pdst counterpart starting with d -- dstatus, dfileopen, drun, dclose. Alright, now you can go and try it with two (at this point still somewhat crude) examples. Get the file
http://www.phenix.bnl.gov/~purschke/pdst_example.tar
untar it, and you will see two directories. pdst_ex1 is a completely simple one, which loops through all DST events and prints out the tree structure. The second example adapts Jeff's Luxor tutorial example #3
http://www.phenix.bnl.gov/phenix/WWW/software/luxor/tut/phool/dst.html
to pdst. Follow the README's and you'll be in business in no time.
And there's more to come. Irina has been working on putting the life back into the PHModuleManager, which lets you break up a complex analysis (you will find that the example 2 looks the opposite of pretty, with basically all analysis crammed into a more or less linear routine) into smaller chunks and do them one by one in a well-managed and coherent way. Stay tuned for that to be integrated with pdst. Ok, have fun, Martin