160 likes | 304 Views
On-Line Monitoring. On-line monitoring review TOF On-line status Recent work About the “ pdst ” Conclusion & Future work. ddEventiterator. testEventiterator. Eventiterator. fileEventiterator. Accessing Data for Monitoring. { gSystem->Load("$EVT_LIB/libEvent.so");
E N D
On-Line Monitoring • On-line monitoring review • TOF On-line status • Recent work • About the “pdst” • Conclusion & Future work.
ddEventiterator testEventiterator Eventiterator fileEventiterator Accessing Data for Monitoring { gSystem->Load("$EVT_LIB/libEvent.so"); h1f = new TH1F("h1f","Test random numbers",100,-49.5,50.5); Eventiterator *it = new testEventiterator(); // random number // new ddEventiterator("online"); // DD Pool //new fileEventiterator ("xx.evt"); // file int iCh = 0; int packetId = 1003; for (int i=0; i<3000; i++) { Event *e = it->getNextEvent(); Packet *p = e->getPacket(packetId); h1f->Fill( p->iValue(iCh) ); delete p; delete e; } delete it; h1f->Draw(); } • ddEventiterator : Read the event data from a data distributor(DD)pool. • testEventiterator : Creates Event objects with known properties from scratch. • fileEventiterator : Read the event data from a data file on disk.
DET FEM DCM EVB The DD pool can have an arbitrary number of inputs, and an arbitrary number of consumers. Data Flow through the Online System The Data Distributor (DD) pool was the main way of distributing Event data after the event builder.
How to access the DDpool To access the DDpool, you have to supply events to the pool artificially. dpipe –s f –d d –w 1 /export/rcfdata/dcm_data/rc/DD_0 Dpipe : Reads events from one source and writes it to a destination. The source can be any of the standard sources (DD pool, file). The destination can be a file or a DD pool. DD_0 : One of pool names. List of options : -s source id dd pool, file -d destination id ddpool or file -w wait time interval between events to throttle the data fllow
Bye-Bye. DD! • bye-bye, DD! • To: "phenix-daq-l@bnl.gov" <phenix-daq-l@bnl.gov>, phenix-off-l <phenix-off-l@bnl.gov> • Subject: bye-bye, DD! • From: Martin Purschke <purschke@bnl.gov> • Date: Fri, 06 Oct 2000 10:19:11 -0400 • Reply-To: phenix-off-l@bnl.gov • Sender: owner-phenix-off-l@bnl.gov • Dear all, • as previously announced, we are going to retire the DD pool and replace it with something better. The most likely candidate for immediate replacement is the "ET" package, developed at Jefferson Lab. The JLab folks had taken the original DD package from ChrisW, and then, getting the same problems we were plagued by, rewrote it from scratch, but preserved the general philosophy. Chris Pinkenburg took that package and at this point it looks promising, very promising. In preparation for the switchover (which may still be a week or two away), I'm going to remove the DD software from the Event libs. In order not to break working things, I will keep the ddEventiterator class around but take its guts out, so that existing libs will get their references satisfied. You won't be able to get data from a ddEventiterator, but your existing libs will load. The change should show up in the nightly rebuilds over the weekend or Monday. Please scream if there's something that doesn't work for you. Unless you actually used the ddEventiterator, you shouldn't see any difference. • Cheers, Martin • -- Martin L. Purschke ; purschke@bnl.gov ; http://www.phenix.bnl.gov/~purschke ; Brookhaven National Laboratory ; phone: +1-631-344-5244 Physics Department Bldg 510 C ; fax: +1-631-344-3253 Upton, NY 11973-5000 ; -----------------------------------------------------------------------
Check for user command prompt/GUI Check for user command prompt/GUI That’s what we had to do before That’s what we do now Get Next Event Get Next Event Analyze event Analyze event Multi-threaded ROOT online monitoring • For online monitoring, we want to work with our histograms, display them at will, clear them, fit them, store them, whatever, while they are being filled in the background by our monitoring task. • In our flow of control, say for GUI’s, we don’t need to bother with the Event loop - that’s the background thread.
Pmonitor framework int init_done = 0; TofOnlCalib* TofOnCalib = new TofOnlCalib(); TofMonitor* gs = new TofMonitor(); TofAddressObject* TofAddress = new TofAddressObject(); BbcEvent *bbcevent; // initial part int pinit() { gs->TofMonConst(); TofAddress>fetchFromFile( "/home/phnxtof/online/monitoring/ParFiles/071800/toffemmap.txt.year1", "/home/phnxtof/online/monitoring/ParFiles/071800/tofcablemap.txt"); return0;} int process_event (Event * e) { e->identify(); gs->setEvent(e); char *prdfFile[10]; for ( int ifile=0; ifile<10; ifile++ ) { prdfFile[ifile] = new char[150]; } ifstream files(fileList,ios::in); if (!files){ return; } else{ files.seekg(0); for(ifile=0; ifile<10; ifile++){ files>>nfile>>prdfFile[ifile]; if(nfile==999){ cout<<"# of file is "<<IFILE<setPRDFFile(prdfFile[irun]); int c = '/'; char *tmp = strrchr(prdfFile[irun], c); gs->setRunName(tmp); gs->TofDataHandle(TofAddress,bbcevent); } return 0; } int pstop() { gs->TofMeanRms(TofAddress, TofMeanFile); // <----FEM check gs->TofGetRunDep(RdepFile); gs->TofMonClose(rootFile); return 0; } Initialize, get histo factory, book histograms, open files,etc. Process an event, which is delivered by the framework End of stream is reached
TOF On-line status until August Get the histograms information Miwako Dong Jin Make the Event Display and showed the histograms with pmonitoring After read the PRDF data and make the histograms.
The problem of the past ***Break *** segmentation violation Root >
The total display using the executable file Got the event data from a DST file(“DST_v01_stream01-0000011477-0048.proot”)
What is the pdst 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.htmlto 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
Conclusion & Future work • First, I will incorporate ET package into on-line monitoring program. • Second, I will put my program on phoncs machine for next shifters after arrange it ,sooner or later. • Finally, I will do PRDF mixing work after I study offline code.