Minute meeting analisi 9 febbraio 2009

Legnaro temporaneamente associato al gruppo dell'Higgs, per via della failure di Roma. Hanno dei problemi di configurazione che non riescono a risolvere, avendo perso il tecnologo che doveva occuparsi del tier. L'utilizzo di CPU di ROMA (CMS e anche ATLAS) e' a zero.

Approvate analysis notes H->WW e H->ZZ. Nella prima c'e' un contributo di Padova. Era stata bocciata per la poca cura nel background W+jets, ora e' approvata (28 gennaio). Lavoro che riguarda i dati CSA07 completato. Serve una piccola appendice per mettere insieme le significatività delle due analisi. La WW ha la combinazione di elettroni, mu, e misti. SOno tre analisi separate. Emu sebbene abbia il doppio di statistica da' un miglioramento di poco piu' di un terzo. C'e' un problema di ottimizzazione. Analisi seguita da Milano e Parigi.

E' uscito il Physics TDR di Atlas, con analisi sulle tipologie di ricerca dell'Higgs, e dovremo dare un'occhiata per vedere cosa riescono a fare loro. La loro analisis embra migliore, perche' con un solo canale e' poco inferiore alla nostra con tutti i canali assieme. Pero' bisogna entrare nel dettaglio delle sistematiche per capire quanto conservativi sono loro.

E' stato diffuso il programma di ripartenza di LHC di Chamonix del 6/2, l'idea e' di runnare a 10 TeV fino ad aver raccolto almeno 200/pb, da fine 2009 all'inizio 2010. Vedi messaggio del DG.

Luca Perrozzi, dottorando del I anno, entra a far parte del nostro gruppo. Precedentemente in MEG, lavora con Franco Simonetto, Carlotta Favaro, Paolo Bellan, Martino Margoni, e T.D. alla comprensione dei muoni per l'analisi multi-muon.

Quadro del cluster: LXCMSEDGE01, LXCMSEDGE02 nuove macchine. Il primo fa da server del software di CMS, tutte le home, e i Raid3 e Raid5. Il secondo gestisce i dischi pari (raid4, raid6). Ci sono poi due macchine vecchie, lxcmssrv in dismissione, lxcdesrv dual core in aggiornamento.
Ugo: le home sono backuppate, i dischi raid sono ridondanti per cui se un disco del cluster si rompe i dati dovrebbero essere salvati. Sulle varie directory vanno messi soltanto i dati, non il software privato. D'altra parte sulle home non vanno messe cose grosse tipo rootuple, per non chiedere al sistema di backuppare decine di Gb ogni volta. Qualche centinaio di Mb da backuppare ciascuno di noi.

Poi messe in funzione lxcmssrv1, lxcmssrv2 che si aggiungono alle 3 e 4. dual core tranne il quad-core lxcmssrv4. Funzionano sia per testare il software, sia come user interface. Potete sottomettere job via GRID, per tutte e quattro.

Messe in funzione anche due 8-core lxcmssrv7 e lxcmssrv8. Attualmente funziona solo il software di CMS, per cui non ancora come user interface. Sono macchine a 64 bit. Le altre hanno il software di CMS; le 7 e 8 hanno installato un patch di compatibilita' che permette di far funzionare il software di CMSSW. Cio' per fare la migrazione verso 64 bit. Installando la nuova versione del software a Legnaro dovremmo aver risolto i problemi, e in teoria dovrebbero tutte diventare delle user interface, anche queste due.
Ugo: se uno sottomette via GRID da una user interface a 32 bit il software a Legnaro, va automaticamente solo sulle macchine a 32 bit, o su tutte ? Va su tutte in modo trasparente.
Michele: il contrario non si puo' fare, da una macchina a 64 non puoi girare su quelle a 32 bit.
Ezio: una volta che la transizione avra' funzionato, anche le altre macchine saranno migrate a 64 bit. Queste macchine dal punto di vista dell'hardware sono da 64 bit.
Michele: faccio notare che ogni core delle macchine vecchie, 1234, hanno 1 Gb per core e potrebbe non essere sufficiente. Quando la macchina inizia a fare page swaps va mille volte piu' lenta. Bisogna provare a lanciare 4,5,6,7,8 jobs per macchina e vedere.
Ezio: allora una volta finita la transizione facciamo una prova sulle macchine vecchie.
Lxcmssrv6 e' temporaneamente out. quad core, in molti la usavano, come annunciato si e' rotto l'alimentatore.

4 Blade DELL, acquistate con fondi GRI, date in prestito ai test della GRID. Ferrari dice che sono nella GRID con priorita' CMS. QUeste macchine avrebbero la funzione di creare un unico TIer padova-legnaro, cosi' qualche macchina e' basata qui con un link a 10 Gbit/secondo. Non mi e' chiaro cosa significhi avere la priorita' CMS.
Stefano: siccome le macchine PD e legnaro si vedono come se fossero una a fianco all'altra, le macchine di Padova dichiarano come close SE Legnaro, cosi' i jobs che arrivano a Legnaro si trovano le macchine di Legnaro e quelle di Padova, scelgono secondo i criteri, e arrivano dove arrivano. La cosa delicata e' come installare il SW sulle macchine di Padova.
Ezio: stai parlando delle blade o tutte le macchine ?
Stefano: conviene farlo su tutte le macchine. Per farlo abbiamo diverse strade, una e' installarle a mano, l'altra e' dichiarare che il CE di Padova e' un TIer 3 di CMS, lo registriamo negli opportuni canali di CMS, e a questo punto l'installazione centralizzata di CMS arriva anche a Padova, e cosi' abbiamo gratuitamente (modulo inst. iniziale) le macchine col software installato e disinstallato quando diventa obsoleto. La terza possibilita' e' di dire che visto che abbiamo banda infinita, montiamo sulle macchine di Padova l'installazione di Legnaro, con un mirror.
Michele: Il problema e' che funzioni tutto molto bene, perche' se un job fallisce e' il T2 che ne paga le conseguenze, quindi si puo' fare quando a PD abbiamo la stessa affidabilita' di Legnaro.

Addendum 10/2 by M. Michelotto:
Ho chiarito la situazione della priorita' di CMS. Tutte le 14 lame sono ugualmente in grid. Vedono gli SE di LNL attraverso il link a 10 Gbps ma non so se sono dichiarate close SE degli SE di LNL. Come diceva Stefano poi manca anche l'installazione del sw di CMS. C'e' una macchina a 64 bit pronta per ricevere questa installazione.
La priorita' si intende che se ci sono job in coda di diverse VO, i job di CMS hanno la precedenza per cui passano davanti ad altri job in coda.
C'e' anche uno slot sempre vuoto che puo' essere occupato solo da un job di CMS. per cui dovreste avere la possibilita' di provare una produzione di un singolo job che accede per esempio a LNL senza aspettare che ci siano slot libere.

Per quanto riguarda Legnaro: nell'ultimo report avevamo Legnaro in stato ottimale con 190 Tb di spazio disco, ma solo 55 usati. Attualmente ci ritroviamo con 176.5 Tb, 140 utilizzati. Esplosione dell'utilizzo dello spazio disco. COme dovremmo garantire noi per supportare EWK, MU e Higgs, sono 30 per RECO data histong, 30 per ogni POG o PAG assegnato, 20 per produzione , andiamo bene cosi'. I 10 Tb in meno sono server dismessi, e anche un blade center da 28 core, circa 30 slots in meno. D'ora in poi avremo un po' di spazio disco e CPU dismesso, e un po' acquistato. Nel 2008 avevamo 450 slots, e 50k euro. A Febbraio 2009 non ne abbiamo piu', spesi per acquistare 33 Tb. Arriveremo a 210 Tb presto. Sono state acquistate CPU per 60 slots. Siamo ora a 480 slots. La potenza di calcolo e' aumentata di piu' in proporzione, fino a 900 kspecint2k.
Dei 140 Tb 100 sono dati in Phedex. Se avete il link del sito di legnaro avete la lista di tutti i datasets di legnaro, 40 occupati dagli utenti come output dei jobs sugli storage elements. Sono tanti 40 Tb, dovremmo indagare chi li sta usando e come, e chiedere di fare pulizia, perche' non ci sono ancora vincoli. Si e' discusso nei Ph. Days di fare associazioni, ogni singolo utente sara' associato al massimo a un paio di tier, ma per ora non ci sono vincoli e si possono creare situazioni degenerative da sanare.

Dovendo ospitare molti dati nuovi sono stati cancellati i dati CSA07 EWK, e pochi giorni fa, subito dopo l'approvazione delle note H->WW e ZZ, sono stati cancellati anche i dati Higgs di CSA07. Insomma di 40 Tb la meta' e' gia' stata rimossa.

Da quando e' uscita la nuova versione di Phedex ogni dataset e' associato a un gruppo di fisica, MU EWK o HIGGS, o centrali (dataops o facops). 51 Tb solo per Craft. 54 Tb solo per i mu, un campione Y(1S), craft e cruzet4. Nel caso dataOps ci hanno chiesto di ospitare pattuple e cosmici. Poi ci sono Summer08 e redigi di Summer08 di EWK. Per l'Higgs solo pochi Tb.

Una nota e' quella della calibrazione, risultati del craft e velocita' di deriva. Si dovrebbero vedere l'andamento di vdrift in funzione delle cinque ruote, per i diversi settori, e in funzione della posizione nella camera. Il campo magnetico radiale modifica vdrift quando e' grande. Questa sara' la prima CMS note finalizzabile. Poi ce n'e' una sulla ricostruzione locale, che ha materiale abbastanza disponibile, si tratta solo di sistematizzarlo. Un layout e' gia' pronto. Si studia il timing, la risoluzione, l'efficienza di hit. Il fit che ricostruisce il t0 dopodiche' uno puo' mostrare le risoluzioni ultime ottenibili, 180-190 micron, confrontabili con quelle che si avranno in collider mode. Differenze nel numero di hits data/MC devono ancora essere guardate. Ricostruiti i segmenti, si possono guardare le distribuzioni angolari come sono attesi da MC e visti nei dati. Cio' dipende da come e' configurato il trigger e bisogna starci attenti.
Nella nota entrano anche le correlazioni angolari fra stazioni successive. Concludere con l'illustrazione del bending power, per la misura del campo magnetico del ferro fra le varie stazioni. Muoni negativi e positivi sui dati, con la misura del trascker, permette di mostrare il bending per momenti diversi. Per le altre note i contenuti non sono ancora stati presentati. Poi ci sara' un muon barrel workshop al CERN il 16-17 febbraio. Dedicata a questi studi. Gli studi sul campo magnetico fatto con le tracce, che vuole essere complementare alle conoscenze del campo fatte con le misure dirette delle sonde, mostrano che il campo magnetico nel ferro e' significativamente minore che quello delle mappe.

Seguendo la traccia in maniera integrale, i residui in posizione mostrano una asimmetria a basso momento fra lower e upper sectors.
Fabrizio: Aachen voleva incollare il superlayer con uno spessore di colla mediamente superiore a quello che abbiamo messo noi. Noi ci siamo opposti a questa operazione.

Studio efficienza di ricostruzione segmenti traccia nei DT e metodo tag & probe. Eventi usati nell'analisi: cosmic muons che attraversano il tracker, globali per avere una topologia simile a quella di eventi con mu da collisioni pp. Circa 2 milioni di eventi.

Considero solo i settori 3,4,5, 9,10,11: sono quelli maggiormente comprendenti i muoni cosmici. L'idea per il calcolo dell'efficienza e' di selezionare eventi per i quali siamo sicuri che la camera sia stata attraversata. mu cosmici in cui un tratto della traccia e' ricostruita globalmente, e l'altro tratto estrapolato da un algoritmo con la mappa del campo magnetico. Vogliamo mostrare il caloclo dell'efficienza in funzione della posizione del segmento nella camera. Per stabilire il valore della distanza entro cui andiamo a vedere se il segmento e' stato ricostruito o meno prendiamo eventi in cui una parte della traccia del muone cosmico e' stato ricostruito "globale", e un tratto stand-alone. Se nella camera attraversata troviamo un segmento che ha contribuito all'interpolazione, calcoliamo il residuo.
La distanza e' studiata per vari intervalli di impulso trasverso per MB1, settore 4, ruota 0. Troviamo fluttuazioni nella perdita di energia nell'alttraversamento del rivelatore, cosi' la traccia estrapolata si sposta dalla traiettoria effettiva, nei versi diversi per muoni di carica diversa.
Ugo: C'e' l'effetto del campo magnetico minore di quanto previsto. Quello e' l'effetto che causa la differenza fra le distribuzioni rossa e nera nei plots di pagina 8. Comunque questo non e' rilevante per lo studio di efficienza.
Richiediamo due triggers locali diversi nel settore cui appartiene la camera che stiamo studiando, per considerare eventi che non siano stati acquisiti grazie alla camera stessa. Costruiamo un volume fiduciale in particolare lungo la direzione longitudinale.
Ugo: per usare una traccia buona per il calcolo dell'efficienza si diceva di chiedere la conferma della bonta' della traccia su un'altra camera. I plots di efficienza mostrano efficienze fra il 94 e il 96% per le camere DT del settore 4, ruota 0.
Paolo Ch.: Cos'hanno quelle perse ?
Antonio: questa perdita non c'e' piu' se si aggiunge la conferma di un'altra camera, si crede solo all'estrapolazione del tracker. Richiedendo una conferma della traccia l'efficienza aumenta a quasi il 100%.

Per il tag-and-probe, l'efficienza stand-alone puo' essere verificata con eventi in cui siamo sicuri che il mu abbia attraversato il rivelatore. Se selezioniamo eventi in cui un tratto di traccia e' stato ricostruito, vediamo se il tratto superiore e' stato visto. Gli eventi taggati sono quelli in cui c'e' una o due tracce stand-alone. Richiediamo che vi sia un tratto di traccia ricostruito globale 2-leg con Pt>15 GeV, |eta|<0.8, e la traiettoria estrapolata deve avere attraversato un DT nell'emisfero superiore. Le probes sono tracce standalone ricostruite nell'emisfero inferiore. L'efficienza e' quindi il numero di tracce standalone sul numero di probes.

Estratto il segnale di Z e determinato la distribuzione del numero di Z in funzione di Pt e eta. Usati samples Summer08, circa 60000 eventi corrispondenti a 47.6/pb. Per il fondo QCD, Pt 80-170 GeV, circa 6M event corrispondenti a 3/pb, QCD 30-80 circa ... eventi. La simulazione MC assume condizioni ideali di allineamento e calibrazione, bassa luminosita', no pileup. Usata la versione CMSSW_2_1_10. I muoni devono essere isolati in un caso, nell'altro si rilassa la richiesta. I due mu devono essere di carica opposta, e Pt>10(5) GeV.
Per i muoni isolati il criterio di isolamento si attua costruendo un cono eta-phi attorno al muone, e se la somma dei Pt nel cono <0.3 e' minore di 3 GeV si considera isolato. Si esclude il muone. Per interpolare la distribuzione si usa una BW convoluta con una gaussiana. C'e' fondo importante anche con il campione di QCD piu' basso. Va controllato se sono veri mu o falsi. QUesto per i mu non isolati.

Il rapporto segnale/rumore e' 5/1 in una finestra intorno al picco. Per i mu isolati c'e' pochissimo fondo. Ci sono effetti non ancora ben modellati che rendono il fit non perfetto.

Le distribuzioni differenziali con mu isolati si trovano con sidebands subtraction. Gli eventi sono corretti con l'efficienza di ricostruzione, considerata scorrelata in Pt rispetto a eta. la Dsigma(Z)/DPt e /Deta viene fuori chiaramente con 50/pb. La sezione d'urto nel range di eta viene 0.883 nb.

Lavoro fatto con P.Checchia per usare il particle flow per determinare l'energia mancante in un evento. Il primo benchmark e' la massa trasversa del W. Si possono sommare i momenti trasversi ricostruiti dal particle flow, usando tutte le info del detector. Quali sono i vantaggi ? Si sono prodotte un paio di matrici ove la missing energy e' plottata in funzione della somma dei Pt dei neutrini MC. Con il particle flow la funzione di risposta e' migliore. C'e' una maggior linearita', e i residui di MET-nu Pt mostrano un miglioramento del 30% nella RMS.
Lo spettro di massa trasversa mostra una miglior rispondenza anche di Mt(W). Si sono usati fondi per studiare cosa si potrebbe vedere del W operando i tagli dell'analisi, Pt(mu)>25 GeV, rapidita' entro 2.0, acoplanarita' fra muone e met. Rigettati eventi con 2 muoni, eventi con top (non ancora usato), e taglio sulla missing Et (non ancora usato). I tagli sul mu sono implementati nell'analyzer, quelli sull'event in un modulo di tipo edfilter. I risultati mostrano cosa si ottiene con la MET dei calorimetri e del particle flow. Il fondo dominante e' quello di Pt fra 30 e 80 GeV. In conclusione PF fornisce una ricostruzione piu' accurata.

Contesto: esercizi fatti sui campioni EW e ttbar, qcd enriched, capendo come si producono le PAT e come si interfacciano i 2 layers della pattificazione. Poi anche l'uso dei candidatemodules, che permettono di creare collezioni e fare selezioni a livello di configuration files. Poi questo diventa utile anche per il lavoro di CArlotta. Con i candidatemodules si possono contare gli oggetti, ordinarli in Pt, creare o manipolare correzioni, calcolare masse invarianti, applicare selezioni e implementare associazioni generato/ricostruito. Per l'associazione gen-rec: per studiare l'efficienza di associazione e i fake rates. Due links nella slide 5 mostrano le PAT gia' fatte per Summer08. Purtroppo nei settings di default delle PAT l'associazione gen/rec e' configurabile, e il default forza l'ID della particella generata ad essere proprio un mu. Primi risultati per l'associazione mu ricostruiti - mu veri, e in Pt e eta di mu veri e falsi, e il fake rate vs Pt e eta. Il fake rate e' la frazione di pi e k visti come muoni.

Altri tools utili: i GlobalSelectors. Selezionano di botto i muoni come si vuole. Uno interessante per abbattere il fake rate e' di richiedere che il muone attraversi il detector -> si chiede che muoia almeno nell'ultima camera del barrel o del forward DT. I muoni vengono associati a tracce non mu meno frequentemente con il selettore TMLastStationOptimizedLowPtTight. Il fake rate ha forti crescite a eta alto.
Ezio: la selezione laststationtight cosa fa ?
Paolo: chiede un segmento sulla ultima stazione.
Ezio: la produzione ufficiale delle pat fa anche dei tagli oltre a convertire i Reco in AOD ?
Paolo: le PAT le puoi produrre dai reco o dagli AOD, puoi scegliere.
Ezio: ma di fatto e' un formato AOD, cui aggiungi alcune infomrazioni.
Paolo: o ne togli.
Ezio: si ma la questione e' di confrontare le pAT con gli skim primari e secondari.
Paolo: c'e' una web page con i settings di default, che sono di solito molto laschi. La PAT ha senso se me la faccio privatamente, prendo l'AOD che sta nel TIER, ci metto i tagli che voglio, e viene piccolissima. Se invece faccio la PAT comune tengo i tagli laschi e tengo tutto.