1 / 27

The ALICE data quality monitoring

The ALICE data quality monitoring. The ALICE experiment. CERN : European Organisation for Nuclear Physics LHC : Large Hadron Collider ALICE : A Large Ion Collider Experiment 18 detectors Trigger rate : 10 KHz (max) Bandwidth to mass storage : 1.25 GB/s. Data Quality Monitoring.

spencer
Download Presentation

The ALICE data quality monitoring

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. The ALICE data quality monitoring

  2. The ALICE experiment • CERN : European Organisation for Nuclear Physics • LHC : Large Hadron Collider • ALICE : A Large Ion Collider Experiment • 18 detectors • Trigger rate : 10 KHz (max) • Bandwidth to mass storage : 1.25 GB/s Barthélémy von Haller - CERN PH/AID

  3. Data Quality Monitoring • Online feedback on the quality of data • Make sure to take and record high quality data • Identify and solve problem(s) early • Data Quality Monitoring (DQM) involves • Online gathering of data • Analysis by user-defined algorithm • Storage of monitoring data • Visualization Barthélémy von Haller - CERN PH/AID

  4. Data-Acquisition architecture Sub-event Sub-event Fullevent DADQM Barthélémy von Haller - CERN PH/AID

  5. The AMORE framework • AMORE : AutomaticMOnitoring Environment • A DQM framework for the ALICE experiment Barthélémy von Haller - CERN PH/AID

  6. Design & Architecture • Publisher – Subscriber paradigm • Database used for the data pool • Notification with DIM (Distributed Information Management System) Barthélémy von Haller - CERN PH/AID

  7. Design & Architecture • Published objects are encapsulated into « MonitorObject » structure • Plugin architecture using ROOT reflection • Modules are dynamic libraries loaded at runtime Barthélémy von Haller - CERN PH/AID

  8. Design & Architecture Barthélémy von Haller - CERN PH/AID

  9. The Pool • Current implementation based on a database • MySQL : light-weight, reliable, freely distributable Barthélémy von Haller - CERN PH/AID

  10. Objects Producers High Level Trigger Prompt Reconstruction Objects HOMER Event Plots, ESD’s, Images Data Pool Monitor Objects Monitor Objects Agent Data samples Clients GDC LDC File Event Histograms Monitor Objects AliRoot QA Detector Algorithms Feb. 25, 2010 – ACAT 2010 Barthélémy von Haller – CERN PH/AID

  11. Subscriber & User Interface • Generic GUI • Display any object of any running agent • Possibility of handling automatically the layout • Layout can be saved for future reuse • Fit the basic needs of the users to check what is published by the agents • For more complex needs, users can develop their own GUI Barthélémy von Haller - CERN PH/AID

  12. The generic GUI Agent Sub-directories Monitor Objects Agents Barthélémy von Haller - CERN PH/AID

  13. Web access • Another type of client : web application • ALICE eLogbook • Possibility to access monitoring information in real time world-wide : • Images • Raw monitoring objects • Statistics Barthélémy von Haller – CERN PH/AID

  14. Logbook integration • Screenshots to show result (list of agents, list of objects, archive, download)

  15. Multithread ing • Motivation : to take advantage of multi-core architectures • First step : • One thread for the analysis (user’s code) => go as fast as possible and therefore monitor as much events as possible • One thread for the images production (heavy process) Barthélémy von Haller – CERN PH/AID

  16. Multithread ing Barthélémy von Haller – CERN PH/AID

  17. Parallelization : future • Add yet another thread for the database operations • Allow users to transparently run a given agent in n processes to collect more data Data sample 1 Final Results Partial results Data sample n Barthélémy von Haller – CERN PH/AID

  18. LHC start-up’s experience • November 2009 : LHC restarts • AMORE intensively used in a real world and production environment • Up to • 35 agents running • 3400 objects published per second in average • 115 MB published per second in average Barthélémy von Haller – CERN PH/AID

  19. LHC start-up’s experience • Example DAQ Barthélémy von Haller – CERN PH/AID

  20. MCH example : (Muon chambers) Too high occupancy -> electronic problem Barthélémy von Haller – CERN PH/AID

  21. LHC start-up’s experience Barthélémy von Haller – CERN PH/AID

  22. Plans • Fully automatize the process : comparisons to reference data, identification of problems, notification, actions taken • Add features to take full advantage of multi-cores architecture • Multiple threads • Multiple processes Barthélémy von Haller – CERN PH/AID

  23. Conclusion • AMORE has been successfully used during the LHC restart and proved to be very useful • Wide range of usages • Capable of handling very large number of agents, clients and objects  The architecture is adequate Barthélémy von Haller – CERN PH/AID

  24. Questions Barthélémy von Haller – CERN PH/AID

  25. Barthélémy von Haller – CERN PH/AID

  26. Archiving • Short-term history : First-In First-Out (FIFO) • Long-term archives : At end of run, regular intervals, and users’ request Access Publish Agent GUI Latest value FIFO X recent values Temporary and permanent archive Archive triggers : Start and end of run, regular time interval, at shifter’s request Barthélémy von Haller - CERN PH/AID

  27. LHC start-up’s experience • TPC : event display in the detector Barthélémy von Haller – CERN PH/AID

More Related