1 / 14

Online Monitoring System at KLOE

CHEP 2000 Padova, 7-11 February 2000. Online Monitoring System at KLOE. Alessandra Doria INFN - Napoli for the KLOE collaboration. NAPOLI. To be used by experts and by shift takers: has to be flexible. The monitoring system.

aiko
Download Presentation

Online Monitoring System at KLOE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CHEP 2000 Padova, 7-11 February 2000 Online Monitoring System at KLOE Alessandra Doria INFN - Napoli for the KLOE collaboration NAPOLI

  2. To be used by experts and by shift takers: has to be flexible A. DORIA The monitoring system An heterogeneous set of tasks perform on online data different kinds of monitoring (detector response, trigger, data taking, beam parameters, data quality ...). Monitoring is managed by Run Control, as DAQ, but the two system are independent. The monitoring tasks get data from the online data stream: • no interaction with DAQ processes • no reducing DAQ performances • minimize data transfer.

  3. To be used by experts and by shift takers: has to be flexible A. DORIA The monitoring system The development of the monitoring tasks has involved experts from all KLOE subgroups. • The tasks are implemented either in C++, C, Fortran • different graphic tools used for display of results Spying : A common mechanism to access online data has been designed and implemented. • get event data as soon as they are available in the online data stream. • do not disturb main data flow.

  4. Online farm data flow Monitoringtask Monitoringtask Monitoringtask Spy daemon Monitoringtask Formatted events to Disk/Tape A. DORIA Packets of sub-events from DAQ chains Monitoring nodes Receiver Online Farm node Builder Recorder

  5. To be used by experts and by shift takers: has to be flexible A. DORIA Spy daemon Monitoring tasks may run locally on a farm node, spying on events directly from the local buffer, or can be distributed on remote nodes. A spy daemon runs in each farm node as event server. Packets of events are read from the local buffer and sent on TCP/IP to remote monitoring tasks. Spy daemonis a standard KLOE process, managed by Run Control in the same way as the DAQ processes. Itruns with lower priority then the other farm processes.

  6. To be used by experts and by shift takers: has to be flexible A. DORIA Spy daemon Spy daemon creates a new thread for each client connection. Three data serving modesmay be chosen by the clients when the connection is established: • pop - the client requests a new packet as soon as processing of the previous one is completed. • pop in advance - the client issues a new request as soon as a packet is received. • push - spy daemon serves asynchronously, until the TCP buffer is full.

  7. Monitoringtask Monitoringtask A. DORIA Online Event Selection To calculate some physics parameters, only special types of events are needed: fast event classification allows to select cosmic rays, e+e-and g g events. Event filters fill output buffers with selected events. Other monitoring tasks can spy on filtered buffers. Recorder Builder e+e- Event Filter g g Recorder Recorder

  8. A. DORIA Trigger Monitor Filters themselves may monitor physics quantities. Trigger monitor selects events (Bhabha and Phi decays) on the bases of trigger data. It calculates DAQ rates, trigger dead time, rate of Phi candidates, average and integrated luminosity. Monitored parameters are displayed in simple a tcl/tk graphic interface.

  9. A. DORIA Histogram Monitoring Thousands of histograms filled during data taking for monitoring of detector readout, FEE and trigger; client-server system, where the server is the central histogram producer and the clients allow histogrampresentation; Both server and client based on ROOT framework. Spy daemon Kbrowser Kserver Kbrowser

  10. A. DORIA Histogram producer and browser KLOE server: • histograms organized in a tree of directories with 5 main branches: Ecal, Drift Chamber, Qcal, Trigger, FEE. • Can save current histograms into ROOT file. KLOE browser: • gets by Kserver the histogram directory tree; • allows the user to browse through the directories; • when a histogram is selected, requests updated data to Kserver and displays it; • when requested, gets updated contents of all the histograms in a directory and displays them.

  11. A. DORIA Event Display and Physics Monitor Full event reconstruction with Analysis_Control (Fortran package used for offline). Specialized I/O module for spying . Physmon: • Spying on filtered streams, calculate physics quantities. • Stores mean values and produces HBOOK histogram file when enough statistics is available. A ROOT based presenter converts HBOOK into ROOT format and displays histograms. Event Display: • OnX (from LAL, Orsay) objects for GUI and 3D graphics.

  12. A. DORIA KID library The KID (KLOE integrated data flow) library contains all the C functions to get data from different data sources. Local event buffers, remote spying, raw data files on disk or archived files may transparently be chosen as input for all monitoring tasks. The same tasks are used for online monitoring and for offline raw data analysis.

  13. A. DORIA Task distribution Monitoring tasks have different requirements as to event processing rate and CPU occupation.

  14. A. DORIA Conclusions • The spying method proved to be powerful and flexible: monitoring tasks are connected to the online system preserving DAQ performances. • Online filters to produce selected event stream turned out to be very useful. • The possibility to merge input events from different buffers is foreseen. • The configuration of the system, managed by Run Control, can be easily modified according to the evolution of requirements.

More Related