Page tree

Alibava run

# of events after the analysis step

SHOULD BEconverterrecoclustering-1merger
13500000500000499999499999499999
11500000500000499999499999499999
8500000   499999
9500000   499999
18500000   499999
24500000   499999
16500000   499999
15500000   499999
33500000   499999
34200000199995199995199995199995
35200000   200000
43200000   200000
38200000   200000
4010000099998999989999899998
41200000   200000
44200000   200000
45200000   200000
46100000100000100000100000100000
595000000   499999
585000000   499998
635000000   499999
66500000   499999
70500000   499999
71500000   499998
73500000   499999
74500000   499999
81500000   499999
84500000   499999
87500000   499999
90500000   499999
93500000   499999
97500000   499999
101500000   499999
104500000   499999

No obvious cuts led to reduction of the events number were found.

The numb. of events drops after the commonmode and reco steps (An event loss happens after the commonmode step for ped. analysis and after the reco step for alibava data analysis): 499999 out of 500000 ev. were processed/saved. The corresponding src files have to be checked.

  • Could be that in some processors' code the counter limit condition has set as "< MaxEvent" while in the others as "<= MaxEvent" - has to be checked.

No obvious limits of the loops in the code were found. What also was observed, that an event loss doesn't always happen after the reco step... weird...

After the merger step

Fig. 2. Fraction of missing events caused by the loss of the input collection(s) either cluster_m26, either original_zsdata.

Only up to few tens of events out of 500000 are missing after the telescope-clustering step; that was indicated on the merger step due to the loss of either cluster_m26, or original_zsdata data collections from the *.slcio files.

  • No labels