DQM-QA Run 3

1. DQM-QA Run 3 B. von Haller on behalf of CWG9 26.02.2013 CERN

2. What do we discuss today ? • The answers to our questions about QA/DQM in Run 3 • Important points to remember • DQM AND QA • Many emails were exchanged, please correct us if we say something wrong  B. von Haller | CWG9 Description | 26.02.2013

3. Challenge n°1 Guess who is in charge of each subsystem • Still true  • We have a complex table • And a mailing list : alice-dqm-contact-run3 • Please check it out B. von Haller | CWG9 Description | 26.02.2013

4. Status B. von Haller | CWG9 Description | 26.02.2013

5. CWG 9 – our demands • What “tasks” (name it agents or algorithms if you prefer) will your subsystem need in Run 3 ? • For each of these task or group of tasks, tell us • Whether it already exist today and if so what is its performance. • What is the expected performance of such a task in Run 3. • How many plots are expected to be produced (for the shifter and for the experts). • Percentage of events needed to carry out the task online (minimum, optimal). • What is the input ? i.e. at which stage will it run ? • How fast the response has to be taken into account in the data flow ? • Whether the DQM/QA results have to become persistent and for how long ? • What does “Calibration QA” mean to you ? B. von Haller | CWG9 Description | 26.02.2013

6. ACO • Contacts : Mario R. Cahuantzi and Arturo F. Tellez • 1 task to monitor the mean of the hits per module in acorde • Details • AT LEAST 130 HZ IF THE SYSTEM RUNS IN 1-FOLD COINCIDENCE, IF IT RUNS IN N-FOLD COINCIDENCE (N>2), WE EXPECT AT LEAST 2 HZDo weagreethatitmeans 130 eventsmonitored per second ? • Same perf in Run 3 as in Run 1 • 1 plot for shifter, 2 for experts • 10% minimum, 15% optimal • Input : RAW DATA, IF NEEDED IT CAN BE AFTER DE EPN (THE RECONSTRUCTION FOR ACORDE IS THE SAME AS THE ONE IN RAW DATA)Clarification needed • How fast ? DURING THE FLPClarification needed • Results persistent for 1 year • Calibration QA ? Doesthiscover the QA and not only DQM ? B. von Haller | CWG9 Description | 26.02.2013

7. CPV • Contacts : Yuri Kharlov + ??? • rawdata monitoring per FLP (first level processor). There willbe 3 FLPs (or 3 LDC) for CPV in Run3. Algorithmwillsimplydecode the raw data stream and extract the amplitude for everychannel. • Details • CPV DQM does not existyet, as its code isstillunderdevelopment in aliroot. • I suppose that the performance willbesimilar to whatwehad in Run1, maybeexcept the computer performance whichmightincreasewith new hardware. • For shifter and experts, 3-4 histogramswillbeenough.Per FLP ? Or merged ? • I wouldsaythat 10,000 eventswouldbeenough to getreasonablyfilledhistogramswithraw data. • input is a rawstreamfrom DDL. • I amafraid the question is not transparent for me.Clarification needed • DQM plots wouldbe good to store as root files, or at least as images in the logbook as we have in Run1.  Forever • weshallbeready to answer questions about CPV calibration within a year, after extensive commissioning of the CPV in the lab. Doesthiscover the QA and not only DQM ? B. von Haller | CWG9 Description | 26.02.2013

8. DAQ • Contacts : B. von Haller • Disclaimer : DAQ agents are currentlydoing a lot of « dataflow monitoring », thismightbe part of another package in Run 3 • 1 task for data sizes (per ddl, per det, per cluster, …), distribution and over time • 1 task for the system delays (e.g. time btw 1st and last subeventreceived in EPN) • 1 task for the compression and acception rates (kind of HLT monitoring) • In Run 1 wehad 1 agent for each detector for them to use whenevertheyneeded (e.g. test) • Details • I can’tfind back this information right away • It is a matter of fillinghistogramsnothing more. Thus the bottleneckwouldbe the input data rate. >100Hz • shifter : 2/det for the size + 2? For the compression rates and acception = <35 experts : 1/FLP or DDL (commissioning) + 1/cluster + 1/class + X for delays = > 1000 • 1% minimal, 5-10% optimal, at the beginningitis important to get a lot to have quickly a first idea. • every stage (raw for data size, sub time frames for delays, time frames for compression) • 1 minute • Shifter : foreverExperts : 1 monthat least, ideally 1 year • nothing B. von Haller | CWG9 Description | 26.02.2013

9. EMC • Contacts : David Silvermyr + many • LED DA task • Details • itexists in Run1 • ~0.1 Hz • ??? • 100% • EMCal/DCAL LED calibration events -> where ?? • ??? • ??? • ??? Doesthiscover the QA and not only DQM ? B. von Haller | CWG9 Description | 26.02.2013

10. FIT • Contacts : T. Karavicheva and A. Maevskaya(?) • Details B. von Haller | CWG9 Description | 26.02.2013

11. HMP • Contacts : G. Volpe and M. Tangaro • 1 DQM + 1 QA (currently) • Details • bothexists (answer question about number of eventstreatedtoday -> detector/taskdependent) • same perf as in Run 1 • 4 plots for shifter, 10 for expert (we are talking about DQM and QA all together) • percentage of whatexactly? for some plots few events are needed, somethinglike 1000, for other plots, wherereconstructedtracks are needed, weneedsomethinglike 10^6 full barrel tracks (5 % in HMPID) • if we are talking about DQM and QA, we have to check all the steps, soraw data, digits, recPoints and ESDs. The agent/task has to runat FLP and at EPN level (If I understoodcorrectly the new framework). • point not clear! • point not clear! • we do not have "calibration QA". B. von Haller | CWG9 Description | 26.02.2013

12. ITS • Contacts : Unclear (M. Masera, S. Beole as placeholders) • Details B. von Haller | CWG9 Description | 26.02.2013

13. MCH • Contacts : Laurent Aphecetche + ?? • See PDF as itisnicelydetailedthere B. von Haller | CWG9 Description | 26.02.2013

14. MFT • Contacts : Gines Martinez ? Cvetan ? • Details B. von Haller | CWG9 Description | 26.02.2013

15. MID • Contacts : Xavier Lopez(+ Diego Stocco ?) • 2 agents on raw data decoding (checkingdecodingerrors+occupancy): • Physicsevent • Scalerevent • 1 agent for matching trigger/tracker (in commonwith MCH) • Details • SEE THE FILE ATTACHED IN INDICO AS IT IS NICELY DETAILED THERE B. von Haller | CWG9 Description | 26.02.2013

16. PHS • Contacts : Yuri Kharlov+ ??? • raw data monitoring per FLP (first level processor). There willbe 14 FLPs (or 14 LDC) for PHOS in Run3. Algorithmwillrunraw data reconstruction till the amplitude and time stampper channel. No further reconstruction (till clusters, particlesetcisforeseen). • Details • yes, Performance isat maximum 1 ms per event per DDL whichisverylikelylimited by data readoutratherthan the computing performance. • same perf as in Run 1 • For the shifterwemayprovide 4-8 histograms. For the expert: 20 histograms. • I wouldsaythat 10,000 eventswouldbeenough to getreasonablyfilledhistogramswithraw data. • input is a rawstreamfrom DDL. • I amafraid the question is not transparent for me. • DQM plots wouldbe good to store as root files, or at least as images in the logbook as we have in Run1. -> forever • PHOS does not calibrate per run, becausephysicsstatisticsneeded for calibration canbeaccumulatedduringmanyruns (a month in Run1). But in standaloneruns PHOS willhesatisfiedwith the same DQM plots which are foreseen for physics data. Doesthiscover the QA and not only DQM ? B. von Haller | CWG9 Description | 26.02.2013

17. PMD • Contacts : S. Jena ? T. Nayak ? Studipan De ? • Details B. von Haller | CWG9 Description | 26.02.2013

18. TOF • Contacts : F. Bellini, D. De Gruttola, A. Alici • We plan to have • 1 task on raw data producing al QC objects: shifter’s and expert’s MO are produced by the same task but flagged differently • 1 task running together with calibration to monitor the maps produced by the calibration (maps of problematic, noisy, … channels) also sent to the OCDB  convenient to merge with the raw data task given that processes such as decoding the raw data, are in common ( see answer on calibration QA) • 1 task running on reconstructed data to monitor t-texp, matching efficiency and residuals, time resolution, start-time measurement, PID-related quantities, … (basically, all that needs the tracking info) • Details • Raw data monitored through DQM – code in YS’s QA fmwk, currently produces 7 shifters + 22 expert plots, Nevt/s to be estimated. No QA task run now with calibration, because output of the calibration is checked with the offline QA task that is used now to check the reconstructed data. • Need more info • O(10) for shifter + O(10) expert plots produced on raw data, O(10) plots for calib, O(30)+O(30) expert plots for reco data • Estimate based on run 1, but accounting for more sophisticated monitoring on raw data:Pb-Pb 10k events needed for minimal QC (optimal = minimal x 10)pp 1M events needed for minimal QC (optimal = minimal x 10) • Raw dataandcalibchecks can run on FLPs or EPNs. Reco data checks need “ESD” equivalent (EPNs)? • Plots shouldbeupdatedevery O(1 min) • Raw data or detector performance MO: some need to be stored permanently, some temporarily available + possibility to store permanently (in logbook?). For the MO on reco data: permanently stored for future reference (very important for analysis) • The TOF calibration performs a series of checks which are also of interest of the QC, eg. check on the readout efficiency, noise, problematic channels… Most of the QC and calibration “steps” are common, eg. decoding of raw data, comparison with some reference/average behaviour it would be natural that QC and calibration share a common framework, that is the calibration process can behave as a QC process, sending information to the shifter/database while performing calib actions B. von Haller | CWG9 Description | 26.02.2013

19. TPC • Contacts : Jens Wiechula + alice-tpc • Details B. von Haller | CWG9 Description | 26.02.2013

20. TRD • Contacts : W. J. Park, J. Mercado, I. Arsene • Probablyweneed to runtwoseparated agents in parallel • Details • and the number of shifter’s plots shouldbe the same for both agent (6 plots now). • DQM must be able to handledifferent TRD data formats and content 1) full rawevent (Run1 data format; in Run3 downscaled by a large factor (eventually >1000) and acquired for calibration purposes) 2) trackletonlyevents: willbe the default data format 3) rawevents ( in the Run1 data format), but data fromelectron candidates only • must handle all the aboveevent types, also mixed in samerun ( tracklet - full rawevents ) • independentdownscaling for DQM for each type ( subset of trackletevents, all full rawevents) • Providethe current DQM functionality for each type --> needs to bediscussedwithin TRD; especially implications for the tracklet data • weshould have the functionality to compare DQM results for full raweventswiththose for tracklet data (to spot discrepancies) Doesthiscover the QA and not only DQM ? B. von Haller | CWG9 Description | 26.02.2013

21. ZDC • Contacts : Nora De Marco + ??? • Wewill use 2 or 3 tasks. One readingraw data from FLP, one reading the reconstructedeventsfrom the grid and eventually one readingintermediateprocesseddata arrivingat the EPNs. • Details • Task 1 willbe the equivalent of today's DQM, task 2 willbe the evolutionof the QA of today. The new eventualtaskreadingfromFLPswillbe a forkof today DQM. The memoryconsumptionwillbesimilar to todaytasks and thereforewe do not thinktherewillbeparticularconstraints on the machine hardware. • For each of the threetasks the analysis of a few hundredevents per second. • For each of the threetaskstherewillbearound 6 plots for the QA shifters and around 50 for the experts. • Wewouldneed to analyze a few hundredevents per second with the possibility to have a good percentage of particularkinds of eventslikecalibration events or to select prescaled triggers (such as the minimum bias triggers fromourown detector) from the bulk of the data flow. In addition wewouldlike to collecteventsthatwillreceiveparticular flags from the FEE. • Wewillcollect data from the three stages. • Wedon'tforesee to use feedbacks from the DQM in an automaticway. The eventualproblemswillbeinvestigated by the experts and appropriateaction willbetaken. In case wedetectsigns of ageing of the detector (at the highestluminosities) wewillenable an update of the calibration objects to beused for the followingrun (or fill). • The output willbelightweighthistogram files thatshouldbekept for future reference. Wewouldbe happy if wewerebe able to re-runmanuallythe algorithms on storedraw data for about 1 week, expeciallyduring the period of setting up. • Following the evolution in time of somefeatures in the ZDC MB spectra and eventuallyupdating the calibration objects. B. von Haller | CWG9 Description | 26.02.2013

22. Vertex • Contacts : • Details B. von Haller | CWG9 Description | 26.02.2013

23. CTP • Contacts : EvgenyKryshen • Weforesee expert and shifter agents. Tasks: - monitoring of busy times, - LM, L0 and L1 input rates, - calibration triggers, - bunchcrossingfrequencies, - class-by-class info such as LMB, L0B, L0A, L1A rates and ratios, - monitoring of interaction records. • Details • Most of the tasksexisttoday. Foreseen changes for run 2: - introduction of LM input lavel and corresponding monitoring. - monitoriung of interaction records. - changes in the number of trigger inputs and classes. Changes for run 3: - possible modifications in the number of trigger inputs/classes. • Difficult to saynow but wecanmeasureit in the beginning of run 2. I do not expect a huge impact • The number of produced plots depends on the number of trigger inputs and classes in the run. I thinkwecanexpect 100 classes in run 3. For each class wewouldlike to measureLMb, LMa, L0b, L0a, L1b, L1a rates and ratios such as L0a/LMb, L1a/L1b etc. In total I wouldexpect maximum expert 1000 plots and ~50 plots for shifters. • Minimum: 1%. Optimal 10%. • We are going to use botheventstream and trigger counters via DIM service. DIM info wasupdatedevery minute whichisalso ok for run 3. « I think an important point for the trigger DQM is to have a source of trigger counters. In run 1 counterswerepublished by CTP via DIM. Shouldwekeepitsimilar in Run3? » • Not sure if I understood the question. • Ken suggested to have all plots persistent and easilybrowsablefrom the logbook (if technically possible). B. von Haller | CWG9 Description | 26.02.2013

24. Conclusion • Thankyou to all participants • Nextsteps • Go back to detectors for missing data • Summarize all this in a table for the TDR • Come up with a proposal for computingneeds • Use thisknowledge to design DQM/QA in Run 3 B. von Haller | CWG9 Description | 26.02.2013