PWG4 Status and requirements

1. PWG4 Status and requirements Gustavo Conesa Balbastre for PWG4 analyzers - AOD transition - EMCAL analysis Issues trigger QA JETAN updates

2. PWG4 analysis modules • Jet Tasks: Christian Klein-Bösing et al. • Photon conversions, GammaConv : From Ana Marin et al. • JCORRAN: 2 particle correlations from Jan Rak et al. • PartCorr: Particle identification (, 0, , e, , …) and correlation (with jets, hadrons … ) package. • Omega3pi: Boris Polichtchouk • Et: Christine Nattrass, Oystein Djuvsland, David Silvermyr,… • CaloCalib: Calorimeters (EMCAL) calibration, re-clusterization module. • UserTasks: Simple user analysis tasks.

3. PWG4 analysis modules • UserTasks: • PHOS_pp_pi0 (used for paper) : Y. Kharlov • PHOS_PbPbQA: Y. Kharlov • PHOS_embedding: D. Peressounko • CaloCellQA: Simplified (smaller?) task for calorimeter QA, Y. Kharlov, O. Driga • DiHadronCorrelations (used for paper): C. Loizides • EmcalTasks: • Fast clusterization • Pi0 PbPb • TriggerQA: To be added to QA train • Physics selection: Emcal data event selection task • …

4. Andreas Morsch Analysis transition to AOD • Preliminary results of a poll among analyzers on the feasibility of the ESD->AOD transition • Main concerns and solutions • Need to study systematic effects of track cuts • Provide loose, standard and tight version of each cut • Use of TENDERS • Move to OADB where applicable • Technical problems • Provide support • Ok, but need to finish current analysis under stable conditions • Prepare transition and compare

5. AOD transition: High pT PID • Ok since golden cut is now part of the AOD Track selection • However, would like to keep the old set of cuts • Effect of cut is not reproduced in MC • Systematic studies • Risk that old cut is used unintentionally

6. AOD transition: Azimuthal Correlations (UE, IAA, Minijets...) • Analysis based on Vtracks (ESD, AOD, ..) • Systematic of track selection still studied on ESD • Proposal • Provide loose, standard and tight version for every selection • Availability of AODs for all MC productions

7. AOD transition: Jet analysis Jet analysis are already AOD based • Jet finding based on AliVTracks • Currently use on-the-fly AOD and central AOD • On-the-fly: ESDInput+FilterTask+AOD/ESDAnalysisTask • On-the-fly AOD analysis used for • Debugging, code testing w/o central AOD • High pTcut development/comparison • Direct AOD/ESD comparison • Production of deltaAODs • Standard AOD jet analyses • Jet embedding on track level (jet background analysis) • Currently relies on ESD input, some modifications needed

8. AOD transition: Other analysis • 3-particle correlations • ESD based • Systematic studies • High pT Strange Particles • ESD for “paper” and “thesis” analysis • Part of the group is working on the transition to AOD

9. AOD transition: p0 from conversions+Calorimeter • Analysis based on ESD • Detailed information for selection of electrons from conversion missing in AOD • Can this selection been done in the FILTER train ? Not already done?

10. AOD transition: g-hadron correlations • Analysis based on Vtrack and VCluster: Transparent for AOD and ESD • Analysis with calorimeter + track need ESD + tender : • Tender Supplies that change frequently, difficult to follow the changes • AOD not consistent with ESD+TENDER • No TENDER for AOD: Calorimeter AOD not filtered with tenders yet. • Could final calibration step be moved to OADB ?

11. AOD transition: Calorimeters • No problem to use AOD in general • Specific problems • Cell time information is not stored on AODs. • Until now we did not need it but recently we are trying to improve noisy cell rejection but it isnot a show stopper to not use AODs. • The matched tracks information is handled differently, but it can be accessed in both analysis. • The dEta, dPhi track-cluster stored in ESDs but not provided for AODs • Avoid complicated track extrapolation to calorimeter in analysis. • Heavy usage of TENDER for some data sets • Exploit OADB • Missing trigger information • To be committed soon

12. AODB • PHOS and EMCAL have prepared AODB objects to correct when necessary during analysis • Energy calibration • Bad channel map • Analysis dependent bad channel map • Super Module Alignment • Time calibration in EMCAL: Available soon

13. Pile-up • EMCAL triggers a lot on pile up events • Time of clusters after channel by channel calibration and bunch crossing shift dependent shift LHC11c triggered LHC11a MB noise Pile up Pile up noise 13/50

14. p+p 7 TeV LHC11c, 4.7 M triggered, V1 Exotic clusters • We observe in data clusters with content different compared to simulation • High energy but number of cells low (shadowed region in upper plot) • We have a strong contribution of such clusters from 5GeV and up • Interpretation, particles traverse the detector and hit directly the APD, producing a spike of energy • Not possible to simulate right now unless we add the APD as sensitive volume • Those cells either are clustered with noisy towers or there is some cross talk effect with neighbor towers • How to get read of them: Sum the energy in neighbor towers with common side, E cross, and calculate 1-E cross / E cell • Lower plot shows this calculation for data, the under the box is not present in simulations • A cut at 1-Ecross / E cell > 0.97 is enough for pp

15. LHC11c, triggered • Cut applied for all cells before clustering, with E > 0.5 GeV • Similar result for all p+p periods studied, with or without trigger • The eCross cut removes effectively exotic events. p+p 7 TeV LHC11c, 4.7 M triggered events, V1 clusterizer

16. Pb+Pb@2.76TeV, LHC10h Min Bias No cut 9 M events, AOD073 • Same behavior in Pb+Pb and p+pfor different clusterizers • A cut at 0.95-0.97 could be optimal, independent of centrality? • CMS has a cut depending on centrality V2 clusterizer After cut

17. Exotic clusters outlook • The cut on E cross seems quite powerful to remove exotic clusters/cells • Both observed in p+p and Pb+Pb events • Methods to discriminate if cell or cluster is exotic at the analysis level available in AliEMCALRecoUtils • https://twiki.cern.ch/twiki/bin/viewauth/ALICE/EMCalCode:HowTo#Exotic_cells_clusters • Main concern: • We are triggering frequently on such clusters • Need to reject events triggered by such clusters! • Don’t try to get a cross section including those events • Under study

18. L1-Gamma patch EMCAL trigger QA • Trigger names hardcoded

19. EMCAL trigger QA • New task to QA EMCAL trigger under development • $ALICE_ROOT/PWG4/UserTasks/EmcalTasks/AliAnalysisTaskEMCALTriggerQA • Fill “simple” histograms from trigger FALTRO and STU and cluster distribution per trigger • Request soon to be used in QA train

20. See Jan Fiete’s presentation on Friday Jet Lego Train • Currently beta testing • Still ESD based • ESDFilterwith PWG4 filter config • Jet finder tasks • Streamlining/debugging on user side going on

21. JETAN developments JETANgoal: read tracks & EMCAL clusters/cells from ESDs/AODs and find jets using a given JetFinder. Current (“old”) Implementation: Readers (AOD/ESD/MC/Kine), Finders (UA1,DA,CDF,FASTJET,..) and a single AnalysisTask interfacing with the Analysis Framework Pros: Modular design / Cons: All the code is driven by a single analysis task Caveat: We often need to run several JetFinders Run the whole code several times (quite big memory footprint especially if neutral particles are included) and time consuming  can be a limitation especially when running on the grid or PROOF. 21

22. JETAN developments (2) Improvements needed in order to: Reduce the global memory footprint and running time => improve efficiency Be able to run smoothly (on the grid / an AF) using the current implementation of the Analysis Framework while using several jet finders sharing one Reader How ? Redesign the object used to feed data to the JetFinders The “old” AliJetUnitArray (big object) was not designed in the spirit of the current Analysis Framework as it did not exist at that time 22

23. JETAN developments (3) • Split the code in 2 tasks: • Exchange databetween Readers and Finders • using an Exchange container: a TTree of AliJetCalTrk • 2 TClonesArray : refs to tracks and EMCAL information • TaskJetsReader • Feeds a JetReader Reading input data (AOD/ESD,…) • Creates and fill the object to be exchanged • TaskJetsFinder(one task per jet finder to be run) • Get Data from the Exchange Container • Run 1 Jet Finder • Create and store output objects (Histograms and output AOD) Allows to run severalfinder Tasks connected to the same reader Task

24. JETAN developments (4) • New Jetan code finished and successfully tested • Locally / Grid / Proof • New code implemented in 2 new AliRoot libraries (libJETANdev and libFASTJETANdev) allowing painless comparisons with the “old” code (libJETAN/libFASTJETAN) Benchmark: charged + neutral analysis using PROOF (SAF) – 48 workers - prelim numbers (p-p LHC11a): 1 Jet Finder : speed gain factor 2.1 Memory gain 25% 2 Jet Finders : 2.3 40% • Physicsvalidation is ongoing (via a Jet Spectrum analysis with EMCAL). The new code will be committed once this last step is completed.

25. Request for simulations in preparation • p+p with PYTHIA jets (gamma-jets) in pT hard bins • Has been very useful for embedding studies on the track level (previous production 10 pT hard bins each ~ 800k) • For high pT QA optional run reconstruction of p+p with Pb+Pb settings • i.e. search windows etc. since jets at high p_T are quite dense and HIJING + PYTHIA may not be feasible with enough stats • Apparently jet production even for p+p with recent EMCAL geometry • EMCAL jet analysis require ~ 6 times more events due to smaller acceptance or "jet triggered simulation” • Increase in simulated events probably feasible for p+p not for HIJING

26. Request for simulations in preparation • PbPb HIJING + JETS (gamma-jets) • Up to now only a small production: one pT hard bin 10k events, need at least  factor of 10 and more pT hard bins for jet spectrum • high p_T QA also possible with single high pT tracks in HIJING • EMCAL: Jet triggered simulation, anyway the case in reality • PbPb MB • For us mainly for high pT QA • Here the more the better for systematics of fakes at high pT (i.e. low pT tracks fluctuating up) • Prefer centrality enhanced sample (e.g. 0-10%)