CS general status on behalf of JAPAN CS Analysis task force team T.Fukuda, S.Miyamoto, Y.Sakatani, Y.Taira 2nd April, OPERA Collaboration

Recieved CS 815 Scanned CS 718 Good candidate CS 476 Recieved ECC 415 VTX confirmed 225

Status  ALL Arrived 686 ev “Black” CS 67 ev 1 st CS 621 ev 2 nd CS 21 ev Not found 45 ev 2 nd CS Not yet 44 ev 2 nd CS waiting 43 ev Not found 192 ev Found 336 ev Not yet 93 ev Found 10 ev Center Area 3 ev Edge Area 42 ev ReScan 39 ev 2 nd CS request 153 ev

Brick finding efficiency Efficiency of 1st CS is ~ 64% (336/528). Efficiency of 2nd CS is ~ 32% (21/66). Brick finding efficiency is ~ x0.318=75% If good track is not found at even 2nd CS, we try 1st CS again with heavy scanning/ manual checks. 2CS at once is important to locate event.

 Isotropic gamma ray from interacted nuclei Back scatter gamma can survive case of upstream event.

One wall upstream was selected as 1 st probable 

Then not found muon on “1 st ” CS. 

Predicted well center of CSD More than 2cm from any edge Sample for wall different due to back scattering estimation Very good prediction at center && looks also good by eye display check  A muon track must be found on CSD !! IF not found  scanning in-efficiency or due to back scatter gamma So N_found= N_sample *( 1-e_wall) *eff_trk If eff_trk was known e_wall can be estimated.

Estimation of Wall miss ID Method of estimation The Number of sample is 114 CC events prediction is center area. 114 CC events  100 events Brick found, 95 events muon found. 95 muons  4/4 : 74 3/4 : 21 So, loss from wall miss ID is estimated about 15%. If we don’t find good track in the case of center prediction, We should extract next wall Brick as 2 nd CS.

Automatic CS Analysis Tsutomu FUKUDA Fundamental Particle Physics Lab, Nagoya-univ 2nd April, OPERA Collaboration

Aim & Method Aim Saving manual check load in CS analysis Method 1. Pick up Good Quality Track (Track Ranking) 2. Check “ muon is exist or not ” (Muon hunting) 3. Check “ VTX is exist or not ” (Direct VTX hunting)

Track Ranking I estimate track quality by using projective Likelihood function. Input for 4/4 track : ph x 4 surf, da (micro-base) x 8, da (base1-base2) x 2 Result Track Ranking Real track Fake track Ranking ValueRealFake A 16 ~40%< 1/10000 B 10 ~1675%1/1000 C 4 ~1090%1/50 D -4 ~ 495%1/4 E ~ -4100%1

Muon hunting Muon candidate is selected following cut mm and mrad from KALMAN or LINEAR prediction. Plot is angle, position deference form prediction (sample is smaller position deference one chosen of KALMAN and LINEAR) 4/4 Rank-A,B,C track is Background free in this region.

Direct VTX hunting Selected track is Rank-A or B. Assumed momentum of each track is 1.5GeV/c. Recognition of VTX is below 1sigma. If muon is exist, VTX is searched below 3sigma.

Automatic CS Analysis Result Sheet Event information Track quality Muon candidate VTX plate 2trk VTX information VTX track

Status muVTX TT maching CCFound 7 Not found3 Found15 Not foundGood4 Bad 21 NCFound2 Not foundGood2 Bad 4 No eye check (33/58) events is eye check free. No eye check eye check

Summary I’m developing Automation of CS analysis. ~57% (33/58) events is eye check free. Almost should be checked by eye is edge event, so I start analyzing edge event.

Summary JAPAN side get 686events. The Number of Brick find event is 364 events. Finding efficiency of 2 nd CS is about 34% Brick finding efficiency (1 st +2 nd CSD)estimated ~75%. For muon sample have been applied 3 out of 4 layer hit selection and ¼ of muon was found by 3 out 4 selection Estimation of Wall miss ID due to Back scatter is about 15%. Event will be located in next wall brick upstream.

Extract at once “all” bricks /event Extract “all” Bricks/event at once ! This makes scanning procedure very simple and no waiting time for 2 nd CS. And this will make speed up of location. OPERA analysis is event by event base. BMS extraction time is also gain in the case of neighbor brick. This is key for 2009 run. If this was not ready for 2009 run, we will face same or even more problem than 2008.

Task Force Team for define Brick to be extracted Task force team Judgment for # of extraction/Ev is needed ! Not brick finding but to define how many brick should be analyzed for a event, event by event. should be analyzed for a event, event by event. Event by event difficulty of brick finding is different Judgment for each event is needed. Center event and very confident  one brick /event Edge event  two bricks/event Corner event  4 bricks/ event Wall is ok ?  two bricks/event A proposal is polishing algorithm by two different technical approach by two different technical approach 1. Define by TT Display check team 2. Define by Probability map team Then comparing score and polish each other.

Status check tool for 2nd brick (especially for 2008 run) Status check tool for requested 2nd Brick is needed to do smooth analysis for edge events Now it is difficult to check which treatment state about the 2 nd brick. It is helpful if the “time stumps” for each step(register Que/Extracted/Developed,Shipped) is seen. Tool for Brick id ? We can know event_id and (wall,side,cell,row) by ourselves. But tool need to get Brick_id by event_id,(wall,side,cell,row) Which state now ? register Que/ Extracted / Developed / Shipped When it will come ? Expected time Expected time