Event selection / characterization software package (OpCarac) Alessandro Bertolin (INFN - Padova)

1. OPERA Collab. Meeting (2/4/09) • Event selection / characterization software package (OpCarac) • Alessandro Bertolin (INFN - Padova) • Ngoc-Tiem Tran (IN2P3 - Lyon) • Special thanks section: • A. Cases (OpRelease support) • S. Dusini (MC generation, useful feedback) • D. Autiero (provides us with his visual inspection results) • A. Meregaglia (useful feedback)

2. Introduction • event selection / characterization software package: OpCarac • MyAna version developed by A. Bertolin, OpMacros version developed by Ngoc-Tiem Tran • MyAna version embed in OpRec starting from OpRec 3.1 • current OpCarac version: v1r6 • purpose: automatically classify the events surviving the Manager (and the OpFilter) cuts in the following classes: CONTAINED, SPECTRO, FRONTMUON, SIDEMUON, UNKNOWN • NB: • if an event fails the Manager cuts it is NOT recorded in the OPERA data base and hence it is lost forever • if an event is wrongly classified by OpCarac it is ANYWAY recorded in the OPERA data base and hence it can be recovered at a later time • possible applications: • electronic detector data analysis, want only the events inside the target: use the CONTAINED class • beam monitoring analysis: use the FRONTMUON and SIDEMUON classes • brick finding: use the CONTAINED class

3. Introduction (cont.) • usage (inside MyAna): • RecoUtils::EventType evttyp; • evttyp = m_TDS->EvtHeader().front()->eventType(); • if( evttyp==RecoUtils::CONTAINED ){ • // CONTAINED events analysis • } • if( evttyp==RecoUtils::FRONTMUON ){ • // FRONTMUON events analysis • }

4. already shown OpCarac v1r6 efficiencies on CC PBPL MC events Bjorken-y = E(W*) / E(nin) in words:fractional energy transferred by theincoming n vertex position of the events not identified as CONTAINED • very large efficiency • no dependence on Bjorken-y • few events lost cluster on the TT outer surface (misidentified as SIDEMUON) • Tiem’s algorithm, based on OpMacros, gives very similar results

5. already shown OpCarac v1r6 efficiencies on NC PBPL MC events vertex position of the events not identified as CONTAINED • Bjorken-y dependence: quick rise with Bjorken-y and then saturation at large efficiency values • very large efficiency only when there is a sizable energy transferred by the neutrino (i.e. large y) otherwise very small TT activity … • not clear right now if the NC low Bjorken-y events would pass the Manager cuts … more investigations ongoing … • Tiem’s algorithm, based on OpMacros, gives similar results

6. OpCarac v1r6 efficiencies on NC PBPL MC events (cont.) • Bjorken-y > 0.5, energy somewhere in the TT should be released, average efficiency is 96 % • what’s the wrong event type for the 4 % misidentified PBPL NC MC events ? NC events with a m track close to the TT sides … 2144 / 2236 FRONTMUON 43 27 20 2 CONTAINED SIDEMUON UNKNOWN SPECTRO • right now at high y the efficiency is 96 % • 43 / 2236 = 2 % will be investigated further … unexpected behavior …

7. OpCarac v1r6 efficiencies on tau MC events • Stefano kindly processed for me a rather large number of tau MC events in the mu, h and e decay modes, generated in the CC and QE channels, occurring in the PBPL volume up to the digit level • I run OpRec 3.1 which embed OpCarac v1r6 (using OpGeom v11r1 to avoid OpRec crashes) • n(t) energyspectrum: • non oscillated spectrum: in the MC file the n(t) energyspectra is set to the n(m) energy spectra • oscillated spectrum: each event is weighted according to sin2(const. Dm2 L / E(n)) … in words: high energy neutrinos do not have enough length L to oscillate between the CNGS source and the OPERA cavern … but high energy neutrinos are the ones identified more efficiently … usually efficiency goes down … • efficiency of what ? • OpCarac efficiency for non oscillated spectrum: n_evts(evttyp==0) / n_evts(no cuts) • OpCarac efficiency for oscillated spectrum: S wi if evttyp==0 / S wi no cuts • Manager (TT) efficiency for oscillated spectrum: S wi if TTTrig==1 / S wi no cuts • OpCarac efficiency w.r.t. Manager (TT): S wi if evttyp==0 && TTTrig==1 / S wi if TTTrig==1

8. TTTrig is a function that returns 1 if in a MC events the highlighted conditions are fulfilled (courtesy of S. Dusini)

9. OpCarac v1r6 efficiencies on tau MC events • nt spectrum OpCarac v1r6 OpCarac v1r6 Manager (TT) OpCarac v1r6 • non oscillated oscillated oscillated w.r.t. to Manager (TT) • oscillated • tau mu CC in PBPL: 4812 / 5 k ~ 96 % ~ 96 % ~ 100 % ~ 96 % • tau mu QE in PBPL: 4760 / 5 k ~ 95 % ~ 94 % ~ 99 % ~ 95 % • tau h CC in PBPL: 4799 / 5 k ~ 96 % ~ 96 % ~ 100 % ~ 96 % • tau h QE in PBPL: 4623 / 5 k ~ 92 % ~ 89 % ~ 98 % ~ 91 % • tau e CC in PBPL: 4784 / 5 k ~ 96 % ~ 95 % ~ 99 % ~ 95 % • tau e QE in PBPL: 4356 / 5 k ~ 87 % ~ 80 % ~ 94 % ~ 85 % Dm2 = 2.43E-3 eV2 • Dm2 was varied in the range from 2 to 4 eV2 … very small efficiency changes ! • OpCarac was so far tuned mostly on data and tested on NC and CC events … as a first trial the results are encouraging … • general behavior: • very high efficiency in the presence of a m track in the final state • lower efficiency if only little energy deposited in the TT • OpCarac v1r6 has a higher efficiency on the events surviving the Manager (TT) cuts … this because events with just a few hits in the TT are removed by the Manager (TT) itself

10. OpCarac v1r6 efficiencies on NC PBPL MC events: one more remark black: OpCarac efficiency, n_evts(evttyp==0) / n_evts(no cuts) blue: OpCarac efficiency relative to the Manager (TT), n_evts(evttyp==0 && TTTrig==1) / n_evts(TTTrig==1) at low Bjorken-y the “soft” events are removed (and hence lost forever) by the Manager (TT) so on the remaining ones OpCarac is more efficient (in classifying them as CONTAINED)

11. data: 2008 OPERA data • MC: sample of contained + external, CC+NC events provided by Stefano • OpRec 3.1, which embed OpCarac v1r6, but using OpGeom v11r1 • MC p.o.t. normalized (1.762E19 pot) OpCarac v1r6 purity • evttyp==RecoUtils::CONTAINED • (*iTK)->dimension()>=5 • (*iTK)->muonID()>0 • first track with these properties • evttyp==RecoUtils::CONTAINED • (*iTK)->dimension()>=5 • (*iTK)->muonID() is never >0 • count how many track event by event MC vertex CONTAINED MC vertex NOT CONTAINED • overall purity, P = 1 - 80 / (1232+491) = 95 % • changed current purity, P[CC] = 1 – 0 / 1232 = 100 % • neutral current purity, P[NC] = 1 – 80 / 491 = 84 % (100 % if there is an extra 3d track)

12. OpCarac v1r6 purity (cont.) • if we make softer cuts on the NC events, to increase the efficiency at low Bjorken-y, we should pay attention not to spoil too much P[NC] • at the MC level, it is of course possible to find out which volume and which interaction, NC / CC, is giving these fake CONTAINED events without any 3d track • according to the results of the previous step if should be possible to work out better cuts to improve P[NC]

13. Conclusions and outlook • introduction of news classes (Antoine’s suggestion): • SPLASH • SOFTCONTAINED: in this way brick finding can be run only on the “more energetic” and “cleaner” CONTAINED events • hopefully the UNKNOWN class will disappear, ALL events will be UNKNOWN only BEFORE the algorithm is run • further investigations: • on low Bjorken-y NC events in conjunction with any trigger development (i.e. any change in Manager level cuts) • on a few 2008 neutrino interaction events not classified properly, do we have any update to the extracted event list (I got the last from Elisabetta on 09/02/02) ? • on the latest OpRec developments • due to a > instead of a >= some SPECTRO events occurring in the 1rst SM RPC may be wrongly classified … easy to fix … • L. Stanco suggested to release a short OPERA Note describing this work, we would like to make it “public”, in this case it can be used as a support reference in other papers • Luca already had a careful reading of the draft, it should be ready for the PTB within one week

15. Data vs MC comparisons: charged current candidates • evttyp==RecoUtils::CONTAINED • (*iTK)->dimension()>=5 • (*iTK)->muonID()>0 • first track with these properties • data: 2008 OPERA data • MC: sample of contained + external, CC+NC events provided by Stefano • OpRec 3.1, which embed OpCarac v1r6, but using OpGeom v11r1 • MC p.o.t. normalized (1.762E19 pot) • the charged current data sample is reasonably well reproduced by MC

16. Data vs MC comparisons: front muon candidates • evttyp==RecoUtils::FRONTMUON • (*iTK)->dimension()>=5 • (*iTK)->muonID()>0 • first track with these properties • data: 2008 OPERA data • MC: sample of contained + external, CC+NC events provided by Stefano • OpRec 3.1, which embed OpCarac v1r6, but using OpGeom v11r1 • MC p.o.t. normalized (1.762E19 pot) • the front muon data sample is reasonably well reproduced by MC

17. Data vs MC comparisons: neutral current candidates • evttyp==RecoUtils::CONTAINED • (*iTK)->dimension()>=5 • (*iTK)->muonID() is never >0 • count how many track event by event • data: 2008 OPERA data • MC: sample of contained + external, CC+NC events provided by Stefano • OpRec 3.1, which embed OpCarac v1r6, but using OpGeom v11r1 • MC p.o.t. normalized (1.762E19 pot) • sharing between no tracks and just one track is 50 – 50 %, both on data and MC • very small fraction of neutral current events with two or more 3d tracks