on-line monitoring

14
1 On-Line Monitoring On-line monitoring review TOF On-line status Recent work About the “pdst” Conclusion & Future work.

Upload: truman

Post on 11-Jan-2016

38 views

Category:

Documents


1 download

DESCRIPTION

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"); - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: On-Line Monitoring

1

On-Line Monitoring

• On-line monitoring review• TOF On-line status• Recent work• About the “pdst”• Conclusion & Future work.

Page 2: On-Line Monitoring

2

DiskD isk

testEventiterator

ddEventiterator

fileEventiterator

D D P oolD D P ool

Eventiterator

{ 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.

Accessing Data for Monitoring

Page 3: On-Line Monitoring

3

The Data Distributor (DD) pool was the main way of distributing Event data after the event builder.

The DD pool can have an arbitrary number of inputs, and an arbitrary number of consumers.

DD Pool

from Experiment

MonitoringProcess

MonitoringProcess

MonitoringProcess

DETFEM

DETFEM DCMDCM EVBEVB

Data Flow through the Online System

Page 4: On-Line Monitoring

4

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

Page 5: On-Line Monitoring

5

Bye-Bye. DD!

bye-bye, DD!•To: "[email protected]" <[email protected]>, phenix-off-l <[email protected]> •Subject: bye-bye, DD! •From: Martin Purschke <[email protected]> •Date: Fri, 06 Oct 2000 10:19:11 -0400 •Reply-To: [email protected] •Sender: [email protected] 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 ; [email protected] ; 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 ; -----------------------------------------------------------------------

Page 6: On-Line Monitoring

6

Check for user commandprompt/GUI

Get Next Event

Analyze event

That’s what we had to do before

Check for user commandprompt/GUI

Get Next Event

Analyze event

That’s what we do now

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.

Page 7: On-Line Monitoring

7

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

Page 8: On-Line Monitoring

8

TOF On-line status until August

Miwako Dong Jin

After read the PRDF data andmake the histograms.

Get the histograms information

Make the Event Display and showed the histograms with pmonitoring

Page 9: On-Line Monitoring

9

The problem of the past

***Break *** segmentation violationRoot >

Page 10: On-Line Monitoring

10

The total display using the executable file

Got the event data from a DST file(“DST_v01_stream01-0000011477-0048.proot”)

Page 11: On-Line Monitoring

11

The each display using the shared object file

Page 12: On-Line Monitoring

12

Historgrams

Page 13: On-Line Monitoring

13

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 t

hat 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 c

lashes. 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

Page 14: On-Line Monitoring

14

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.