220 likes | 299 Views
CS general status. on behalf of JAPAN CS Analysis task force team T.Fukuda , S.Miyamoto, Y.Sakatani, Y.Taira. 2nd April, OPERA Collaboration meeting @Ankara. Recieved CS 815. Scanned CS 718. Good candidate CS 476. Recieved ECC 415. VTX confirmed 225. Status. Not yet 93 ev. ReScan 39 ev.
E N D
CS general status on behalf of JAPAN CS Analysis task force team T.Fukuda, S.Miyamoto, Y.Sakatani, Y.Taira 2nd April, OPERA Collaboration meeting @Ankara
Recieved CS 815 Scanned CS 718 Good candidate CS 476 Recieved ECC 415 VTX confirmed 225
Status Not yet93 ev ReScan39 ev • ALL Found336 ev 2nd CS waiting43 ev 1st CS621 ev 2nd CS Not yet44 ev Not found192 ev Arrived686 ev 2nd CS request153 ev Found @ 2nd CS21 ev Not found45 ev Center Area3 ev Edge Area 42 ev “Black” CS67 ev Found 10 ev
Brick finding efficiency • Efficiency of 1st CS is ~ 64% (336/528). • Efficiency of 2nd CS is ~ 32% (21/66). • Brick finding efficiency is ~ 0.636+0.364x0.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. m
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 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 • Method of estimation 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 2nd CS.
Automatic CS Analysis Tsutomu FUKUDA Fundamental Particle Physics Lab, Nagoya-univ 2nd April, OPERA Collaboration meeting @Ankara
Aim & Method • AimSaving manual check load in CS analysis • Method1. 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 4surf, da(micro-base) x 8, da(base1-base2) x 2 Track Ranking Result Real track Fake track
Muon hunting • Muon candidate is selected following cut.+-25mm and +-50mrad from KALMAN or LINEAR prediction.Plot is angle, position deference form prediction (sample is smallerposition 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
No eye check No eye check No eye check No eye check No eye check No eye check eye check eye check Status (33/58) events is eye check free.
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 2nd CS is about 34% • Brick finding efficiency (1st+2nd 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 2nd 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. 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 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 2nd 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