Monika

UK e/gamma Meeting: 

UK e/gamma Meeting Agenda Introduction MW Status of Robustness Studies Andrew Current work and future Plans Graham Current work and future Plans Stathis AOB (next meeting…) This is more of a discussion, so ask questions! Tell us your ideas

Introduction: 

Introduction Will try to summarise what I think needs to be done in future to select electrons and photons Note: Don’t know overall PESA plans and priorities Emphasis on tracking performance Priority on near term plans and what we could do for Rome physics workshop I have certainly forgotten some topics I got dragged away in strange athena problems yesterday and wrote the slides last night…

Upcoming topics: 

Upcoming topics Improve testing/validation of releases So far we are always ‘limping’ behind the releases Improving testing will help keeping up to date with changes and spot them asap Aim at improving testing/monitoring in nightlies and in Root analysis framework (Antonella, Graham) Improve code to allow ‘easier’ debugging, in DEBUG mode we are swamped by too many messages from ‘everywhere’ Analysis of TB data Wrap-up of DC1 results using new ntuple production Will be reference for DC2 Get out new rates/efficiencies after diverse ‘bug-fixes’ To do so Validate performance in 9.0.x before prod of ntuples To do so we will have to update analysis framework so that it can deal with new ntuples Improve analysis framework to be able e.g. to deal easily with single/double object triggers, switch from e to  …

Study Tracking Performance: 

Study Tracking Performance Compare different LVL2 tracking algorithms IDscan vs. SiTrack IDscan/SiTrack + xTRT/TRTLut, IDscan with extention to TRT (Graham) Which combination gives the best tracking performance? Currently LVL2 tracking uses offline SP’s, move to online SP’s Do robustness studies Check/tune performance using initial layout Sometimes more than one track per RoI, find criteria to select the ‘best’ track do be used for cluster-track match Study track performance in TB (Julie, Marc) Might help to improve tracking performance Will organise a small meeting with people interested in TB analysis during SW week

Some more topics: 

Some more topics Electron selection also needed in B-physics (Bill) Try to cover the whole range of pT Develop algorithms which does eff/rate tunings automatically In the future look more in detail at different threshold settings and higher efficiencies (more realistic on day1) We can’t do this by hand forever… Study other selection methods compared to ‘hard-coded’ cuts Performance of EF Run “offline” in EF running mode More emphasis on system performance Monitor consistently timings and give feedback See how we can improve, e.g. reducing RoI sizes

Some more topics: 

Some more topics More technical issues Add complete set of hypothesis algorithms for electrons and photons Work on persistification of LVL2 objects Would be good if we have something easy we could use for Rome on AOD level Test steering with more complex trigger menus Default electrons, photons triggers + pre-scaled e/ triggers (+ muons, …)

What we could do for Rome: 

What we could do for Rome Finalise analysis of TB results Studies using full simulations Rome studies will be done using initial layout We’ll have to tune our e/ selection cuts for this set Importance to get analysis framework in good shape, so that it will be easy to move on to DC2 In case we can get something like AOD’s we need to write code which reads them and fills again our ntuples as we have now Estimate trigger efficiencies using Zee (Manuel) Study trigger selection on other physics channels (similar to what Valeria did for Higgs)

What we could do for Rome: 

What we could do for Rome Look at We(+jets), Zee(+jets) cross-sections (Graham, Antonella, MW) We +jets important background for Susy searches We(+jets), Zee(+jets) important channels for physics on day 1 Study of this channel will Help to understand monitoring/commissioning issues Serve as test bench to study impact of mis-calibrations, mis-alignments… Study impact if we have to increase trigger thresholds, pre-scaled trigger needed? Requires also looking at ETmiss Use ‘offline’ reconstruction as prototype Set-up e+ETmiss trigger useful for monitoring ‘loose’ connection to other groups Study cross section for direct photon production Similar comments as above but for photons

On longer time-scale: 

On longer time-scale Continue studying We(+jets), Zee(+jets) Comparison e with   importance to get overall trigger menus evaluated for the complete set Needs for classification e.g. is EF responsible to send Zee to calibration farm? Perhaps use We as case study for secondary RoI’s to learn how to treat those? Study impact if we have to increase trigger thresholds, pre-scaled trigger needed? Develop strategies for commissioning, assuming different start-up scenarios using exp. Detector performance at that time Don’t forget the uncertainties due to mic-alignment, mis-calibration…  accept higher backgrounds Just little luminosity (at least that’s easy) But still requires looking at more detail at lower pT e/’s

On longer time-scale: 

On longer time-scale Trigger rate too high, what do we do in detail Just raise thresholds? Kick out barrel/EC transition region? Add more selective trigger menus Understand what’s the rate of additional pre-scaled triggers needed if we raise thresholds Understand better needs / additional triggers(?) for calibration and alignment