The ALICE DQM Software and ROOT

Experiences, limitations and suggested improvements

The ALICE DQM Software and ROOT

ROOT Users WorkshopBarthelemy von Haller & Adriana Telesca

for the ALICE DAQ Collaboration

• ALICE : A Large Ion Collider Experiment 18 detectors Trigger rate : 10 KHz (max) Bandwidth to mass storage : 1.25 GB/s

• Online usage of ROOT « ROOTification » Detector algorithms Data Quality Monitoring

ROOT in ALICE Online

11/03/2013 Barthélémy von Haller & Adriana Telesca, ALICE, PH department, CERN 2

• 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

Data Quality Monitoring


• AMORE : Automatic MOnitoring Environment

• A DQM framework for the ALICE experiment

The AMORE framework


• Publisher – Subscriber paradigm• Database used for the data pool• Published objects are encapsulated into

« MonitorObject » structure

Design & Architecture


MonitorObjects


• Dictionaries allow introspection in the client

• Standard ROOT interfaces Easier for users, e.g. call Draw() blindly

• MOTObject allows embedding custom types

• Data pool implemented as a database TMessage used to serialize MonitorObjects TMySQLServer et al.

• Plugin architecture using ROOT reflection Modules are dynamic libraries loaded at

runtime• Custom and generic GUI (see next

slides)• Macro for quick post-processing

without releasing new version of a module

AMORE and ROOT


• Detectors custom GUI Expert view of the data their agent

publishes

User interfaces (1)


• Generic User Interface Based on TRootBrowser, custom

TGListTree TXMLEngine for layouts and preferences

files

User interfaces (2)

11/03/2013 9

• Web access to images of the plots via the ALICE eLogbook

Web access

Barthélémy von Haller & Adriana Telesca, ALICE, PH department, CERN 10

• ROOT provided key features C++ database interface Plugin mechanism GUI Macros XML

• We could have done the same with a palette of tools, here we got it all at once

• Quick, kind and effective support• Still, anything can always be improved…

Experience


• ROOT not web friendly (Bertrand gives us hope!) View and manipulate ROOT objects like in a TCanvas/GUI Others are working on solutions, lack of concertations ?

• Axes are not easy to manipulate Responsibilities are unclear (histo, pad, axis) Time-based axes should be far easier to use

• Objects ownership E.g. TH1 with « functions » encapsulated in a MOTObject E.g. THStack (main histo is destroyed, not the others)

• CMake: missing FindROOT.cmake or ROOTConfig.cmake• Using ROOT as a simple library (no TApplication)

We want our core files and stack traces

Difficulties (1)


• Histograms hierarchy is wrong• Sometimes obscure or inconsistent class

interfaces E.g. TMessage::EnableSchemaEvolution() does actually

nothing if not used in conjunction with TSocket E.g. Zoom is a property of TH1 != draw option and log

scale are properties of TPad• GUI: powerful but writing them is tough, error

prone and pretty verbose• Support

Too often the answer is « Why don’t you do it this way? » instead of fixing the issue

• C++ standard or ROOT standard ? STL, Boost, Collections and types

Difficulties (2)

11/03/2013 13

Code name « redemption »1. No major new features2. Fix the (base) classes inheritance and

interfaceso Hopefully it can even be backward compatible

3. Make ROOT web friendly4. Make ROOT looks nice

o GUI and graphics need a modern look and feelo Simplify GUI programming while you are at it

Prepare ROOT for the next 20 years and protect future users from mistakes made 20 years ago.

My ideal ROOT 7


• The ALICE DQM uses and relies on many features of ROOT

• ROOT provided a very complete toolbox which helped us develop effectively AMORE

• ROOT is going to be used for many more years and, today, there is an opportunity to fix long-standing issues

• Thank you for all the good work !

Conclusion


Backup slides


TMessage and objects evolution


ProducerROOT v. X

ConsumerROOT v.

Y>XTMessage Databa

se

MonitorObject

MonitorObject

MonitorObject

Streamer

Incompatible and no Streamer

EnableSchemaEvolution

EnableSchemaEvolutiondoesn’t actually help.It only raises a flag in Tmessage that is used byTSocket

Web ROOT


An event (click) means a histo must be drawn 1. Get histo1

2. Use a special printer or method on the object

3. Send back the JSON or HTML5+JS or SVG+SMIL

myDiv.content = JSROOT.Draw(json)

Another approach

HTTP request (AJAX)Ask for data of histo1

JSON data

HTML5+JSSVG+SMIL

OR

myDiv.content = data

ServerClient

• JSON : close to what BB is doing, still people can easily use the js lib alone.

• Need for a performant and complete histograming JS library

• Adding DrawWeb() to classes seems a reasonably important effort (?)

• Creating a specific printer might even be simpler

• If no printer/method available for a certain type, simply degrade to generate an image.

• HTML or SWIG is lighter for the client but today clients (browsers) are powerful

Web ROOT


• To be done in the JSON option: Client

oOptionally develop a facility js library to handle the request to server and the drawing in a div

Server / ROOToFind the best way of generating JSON for any

object (new Printer or addition method in TObject). If not defined fall back to an image ?

ClientoDevelop an efficient and complete

histograming javascript library (drawing and manipulation). Usable without ROOT.

Web ROOT


Documents

The ALICE DQM Software and ROOT