RUN100

From BESIII Ferrara Group Wiki
Jump to: navigation, search

Dal run 29 al run 100 sono cambiate diverse cose, le riporto dal logbook (https://www.icloud.com/numbers/07VsZx5pNnQVGofvrA6h4I1bg#LogBook_Data_Taking_IHEP)

GUFI: 3 -> 2++ doppia soglia: T=3 ed E=2 -> T=2 ed E=3 8/10bit error: non trattato -> disabilità chip con errori

Non so se sul logbook cartaceo ci sia altro da segnalare, sicuramente sono stati mossi i cavi, controllato il grounding ma non credo nulla di macroscopico. Il timing del trigger segnalato sul logbook risale al run 29, quindi il run 100 dovrebbe avere lo stesso trigger del 29.

Il run 29 aveva diversi problema ma tutto sommato era un buon inizio. Il run 100 è un vero disastro. Non penso che la bassa efficienza di trasmissione possa spiegare una perdità così grande di dati.

Riguardo i canali noisy: FEB 23 chip 0 channel 26 -> noise alta carica -> come riportato da Fabio FEB 32 -> suspicious noise at 10 fC -> noise piccato in tempo Contrariamento a quanto riportato da Giulio da run differenti, io nel run 100 ho contato 50 eventi di rumore ogni 3ns -> noise rate ~ 6.3 MHz a canale

Riguardo trigger time: il segnale temporale c'è ma è stretto: 1/4 del normale. Sta nel posto giusto quindi non ci sono shift in tempo dovuti alla finestre di trigger. Il problema è che è stretto e questo non va bene perché non ha senso. Visto che non ci sono cariche maggiori di 20 fC, dubito che possa essere segnale. Ad esempio andando a vedere i tempi degli hit di cluster con più di 3 hit, si vede che: --> questi tempi non sono nella finetra temporale corretta ma sono random --> il tempo relativo di questi hit dello stesso cluster è ragionevole intorno ai 20 ns (non capisco) (stiamo parlando di 1200 cluster su 12k eventi e 3 piani di ricostruzione)

Riguardo i dati: c'è un ana.root per ogni SubRUN, siccome il tcount viene riazzerato all'inizio di ogni subrun non si poteva mischiarli tutti assieme. Si possono avere tutti i file assieme nel event.root che risulta avere le stesse informazioni del ana.root più le informazioni sulla calibrazione e il tempo del trigger. Per quanto riguarda il run 100 ho usato solo i primi 20 SubRUN e non tutti 1500. Si hanno comunque 12k eventi di trigger.