1

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)

OPERA Collab. Meeting (2/4/09)

2

• 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

Introduction

3

• 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

}

Introduction (cont.)

4

OpCarac v1r6 efficiencies on CC PBPL MC events

• 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

vertex position of the events not identified as CONTAINED

Bjorken-y = E(W*) / E(in

in words:fractional energy transferred by theincoming

5

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

OpCarac v1r6 efficiencies on NC PBPL MC events

6

• 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 ?

CO

NT

AIN

ED

SP

EC

TR

O

FR

ON

TM

UO

N

SID

EM

UO

N

UN

KN

OW

N

NC events with a track close to the TT sides …

OpCarac v1r6 efficiencies on NC PBPL MC events (cont.)

2144 / 2236

20

2

4327

• 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)

• energyspectrum:

• non oscillated spectrum: in the MC file the energyspectra is set to the energy spectra

• oscillated spectrum: each event is weighted according to sin2(const. m2 L / E()) … 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: wi if evttyp==0 / wi no cuts

• Manager (TT) efficiency for oscillated spectrum: wi if TTTrig==1 / wi no cuts

• OpCarac efficiency w.r.t. Manager (TT): wi if evttyp==0 && TTTrig==1 / 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

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 %

OpCarac v1r6 efficiencies on tau MC events

• m2 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 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

m2 = 2.43E-3 eV2

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_evtsTTTrig==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)

• 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)

OpCarac v1r6 purity

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

• 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

Conclusions and outlook

14

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

• 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

Data vs MC comparisons: front muon candidates

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