La ricostruzione dei dati raccolti dai sotto-rivelatori dell’esperimento CMS `e implementata nel Software framework ufficiale di CMS, diventato CMSSW; esso `e usato sia per l’offline che per l’online e quindi integra i pi`u svariati pacchetti di codice dedicati, dall’acquisizione dati al trigger di alto livello, dall’analisi dei dati reali alla produzione dei dati simulati.
Il software CMSSW `e scritto nel linguaggio di programmazione, orienta-to agli oggetti, C++ed `e concepito come un vastissimo insieme di pacchetti contenenti moduli di vario tipo, dalla diversa funzionalit`a (producers, filters,
analyzers), per gestire l’intera catena di ricostruzione degli eventi. Esso
de-finisce anche i vari formati in cui l’informazione viene resa disponibile nel codice e fornisce un ampio spettro di strumenti (tools), utili per l’analisi dei dati. I moduli sono assemblabili sequenzialmente in una catena che rap-presenta il processo di ricostruzione da eseguire; l’assemblaggio logico viene gestito da un sistema di file scritti in Python, un linguaggio di program-mazione dinamico, di alto livello, usato come scripting language. Questi file di configurazione specificano quali dati analizzare, quali moduli usare per l’analisi e in quale ordine eseguirli.
I dati sono immagazzinati nel cosiddetto Event Data Model (EDM), capace di gestire informazioni diverse, provenienti dalle simulazioni Monte Carlo, dall’elettronica di lettura dei rivelatori (hit) o da oggetti di alto livello parzialmente ricostruiti, come collezioni di tracce, muoni o jet. L’EDM `e centrato sul concetto di Event, inteso come contenitore di dati sia grezzi che ricostruiti concernenti un dato evento fisico.
Per confrontare i risultati ottenuti nei dati con le previsioni dei modelli teorici, si impiegano tecniche Monte Carlo (MC) per produrre eventi si-mulati, utilizzando diversi “generatori”, a seconda del processo in esame. Alcuni fra questi sono PYTHIA, AlpGen, HERWIG e Madgraph. Gli eventi generati sono propagati nell’apparato di rivelazione la cui dettagliata de-scrizione `e preliminarmente stata implementata in GEANT4, in modo da simulare la risposta dei rivelatori di CMS, il trigger e la catena di ricostru-zione dell’evento. I campioni di dati simulati, di segnale e inclusivi, usati nel
presente lavoro sono stati generati con Pythia accoppiato ad EvtGen come “decaditore” e sono riportati nella Tab. 3.1.
Descrizione # eventi (×106) 1 B0 → J/ψ(ψ(2S))[→ µµ]X [72] 8.6 2 B+→ J/ψ(ψ(2S))[→ µµ]X [73] 8.3 3 B0 s → J/ψ(ψ(2S))[→ µµ]X [74] 2.0 4 B±→ J/ψφK± (PHSP) [75] 11.3 5 B±→ Y (4140)K±→ J/ψφK± [76] 4.9
Tabella 3.1: Campioni di dati simulati usati per la presente analisi. I primi tre sono campioni di mesoni B inclusivi usati come campioni di fondo. Il quarto campione (PHSP indica la generazione in puro spazio delle fasi) `e stato usato per la stima dell’efficienza relativa sul Dalitz Plot ed `e stato prodotto privatamente secondo la ricetta ufficiale. Il quinto campione si riferisce a 28 sottocampioni Monte Carlo di puro segnale (con il segnale
Y → J/ψφ generato attribuendogli ben 28 diversi valori di massa) ed `e stato
usato per stimare:
l’andamento della risoluzione in massa del mesone B in funzione della massa invariante J/ψφ;
l’efficienza assoluta di ricostruzione del mesone B in funzione della massa invariante J/ψφ;
la risoluzione in massa del sistema J/ψφ in funzione della massa inva-riante J/ψφ.
3.6 Muon primary dataset e preselezione degli
eventi
Come descritto nel paragrafo 2.4.5, l’esperimento utilizza un sistema composto da diversi livelli di trigger per selezionare in linea solo gli eventi interessanti per il vasto programma di fisica di CMS. Tali eventi sono sud-divisi in diversi primary dataset, sono catalogati in base alle caratteristiche dell’evento selezionato, in accordo con dei criteri predefiniti. Per es. il Muon
primary dataset contiene solo gli eventi in cui la ricostruzione “veloce” del trigger ha individuato uno o pi`u muoni.
Una prima ricostruzione di questi dati `e eseguita entro poche ore dal-la loro registrazione, presso il Tier-0 del Cern, per consentire una rapida validazione degl stessi (offline Data Quality Monitoring). Una seconda rico-struzione (Prompt Reconstruction), in cui sono utilizzate versioni aggiornate delle costanti di calibrazione e di allineamento nonch´e degli algoritmi
sof-ware, viene eseguita successivamente ed entro tempi ragionevolmente brevi.
Questa ricostruzione Prompt, tipicamente eseguita presso i Tier-1, pu`o es-sere ri-eseguita a distanza di tempo, una o pi`u volte a seconda delle neces-sit`a, per incorporare calibrazioni ottimizzate e miglioramenti del codice di ricostruzione. In tal caso si parla propriamente di Re-reconstruction.
Le prestazioni rapidamente variabili dell’acceleratore si riflettono sulle condizioni di presa dati. Per esempio i trigger usati nella definizione dei
primary dataset del 2011 presentano requisiti inizialmente pi`u blandi ma diventati via via pi`u stringenti all’aumentare della luminosit`a istantanea e del corrispondente effetto di pile-up.
I dati reali incorporati nel Muon primary dataset sono stati analizzati a partire dalla versione Prompt o Re-reco usando alcuni specifici analyzer, appositamente implementati, configurati mediante script in Python e inte-grati nella release 4 2 8 patch7 di CMSSW. Nella prima fase dell’analisi, il volume dei dati `e stato ridotto, grazie ad una selezione preliminare degli eventi, eseguita mediante appositi filtri e un insieme di criteri di preselezio-ne implementata preselezio-negli analyzer. Questa prima fase viepreselezio-ne eseguita su una
user interface che permette di accedere, tramite l’interfaccia Grid, ai dati
d’interesse ospitati da alcuni Tier-2, fra cui anche quello di Bari.
Le collezioni di eventi preselezionati vengono prodotte, in questa prima fase, in forma di ROOT file. Non tutte le informazioni presenti nel formato
RECO dell’evento vengono travasate in questi file, mentre molte altre
in-formazioni specifiche vengono aggiunte (p.es. le caratteristiche cinematiche dei candidati composti (J/ψ, φ, mesoni B), la probabilit`a dei fit di vertice, le distanze di volo, le separazioni angolari fra candidati composti e tracce). ROOT[80] `e uno strumento di analisi dati, implementato in C++, svilup-pato nell’ambito della comunit`a della Fisica delle Alte Energie, che consente
di gestire grandi moli di dati, riducibili in base a criteri di selezione imple-mentati dal singolo utente, nonch´e fornire rappresentazioni grafiche, e stima-re parametri mediante interpolazione dei dati ottenibile applicando tecniche di minimizzazione che ricorrono al principio di massima verosimiglianza o al metodo dei minimi quadrati. Per poter usare ROOT, l’informazione da trat-tare deve essere immagazzinata proprio nei ROOT file e quindi organizzata in specifiche strutture gerarchiche chiamate, in gergo, root-uple.
Le informazioni associate agli eventi preselezionati ed immagazzinate nelle root-uple occupano una rilevante quantit`a di spazio disco, dal momento che la preselezione `e stata volutamente implementata conservativa. Queste
root-uple costituiscono l’input per la successiva fase dell’analisi, che applica
algoritmi di riduzione pi`u raffinati e richiede numerosi cicli di ottimizzazione, sia per il raffinamento della selezione sia per i controlli successivi che per l’eventuale studio delle sistematiche.