1 / 17

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

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)

cassia
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  14. 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

  15. 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

  16. 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

More Related