MINUTE DELLA RIUNIONE DEL CONSORZIO TRACKER

MINUTE DELLA RIUNIONE DEL CONSORZIO TRACKER ITALIA DEL
4 e 5 SETTEMBRE 2003 (CATANIA).
4 SETTEMBRE: TISB
Agenda:
15:00
15:05-15:20
15:20-15:30
15:30-15:45
15:45-15:50
15:50-16:30
16:30-16:40
16:40-17:00
17:15-17:45
17:45-18:05
18:05-18:30
18:30-18:45
Inizio riunione
Mini-tutorial su OSCAR - Tommaso
Discussione
Stato del DC04 – Simone
Discussione/problemi relativi al DC04
Discussione sui canali di benchmark del Physics TDR e coinvolgimento
italiano
Mass Tag - Daniele
Root vs HBOOK in TT6 - Suchandra
Noise Studies - Suchandra
Stato delle analisi in sede – Tutti
Rapid Note sul test beam di maggio per conferenze (parte TIB) - Tutti
Varie ed eventuali
Tommaso: Mini-Tutorial su OSCAR
Per le analisi private non dovrà più essere girato CMSIM ma OSCAR. Stato attuale: OSCAR è in
fase avanzata di validazione, cioè non tutto è stato controllato, ma ciò che è controllato è a posto.
Mancano i check del b-tagging e del tau-tagging. OSCAR è integrato con ORCA 7_3_X, cioè
funziona bene con root, con POOL si hanno ancora delle pre-release.
Schema operativo: con CMSIM bisognava produrre il file .fz (in fortran). Questo step si salta con
OSCAR.
Per trovare OSCAR: scram list OSCAR. La release da usare al momento è la 2_3_2. Geometria: di
default viene caricata l’ultima geometria disponibile di CMS.
Il file da editare è essenzialmente il .orcarc. Da qui si può selezionare la possibilità di leggere eventi
CMKIN o da ParticleGun. In più si introducono nome della ntuple, evento di inzio ecc. E’
sconsigliabile toccare altre opzioni: ce ne sono un centinaio.
Ci sono moltissime altre cose in OSCAR, e Tommaso è disponibile a spiegare i dettagli in privato.
Per runnare:
`eval scram runtime –csh`
source writeTrigger.csh
questo serve a settare l’ultima geometria disponibile.
Il campo magnetico non è ancora disponibile in C++.
Siamo a livelli di milioni di eventi processati con OSCAR. Come tempi siamo ad un fattore due
rispetto a CMSIM, il chè sembrava impossibile fino a poco tempo fa. Il 95% dei job va a buon fine.
Per il restante 5%, si sa il motivo del crash nell’80% dei casi.
Simone: Stato del DC04
Si discute del pcp, cioè il pre-challenge. Per la schedule: giugno 03 generazione dati (CMKIN).
Luglio 03: inizio ufficiale (in realtà alcuni siti non hanno iniziato). Fine agosto: OSCAR pronto
(siamo ancora alla pre-release). 10 ottobre: dovrebbe inixiare la digitizzazione. 31 dicembre 03: fine
pre-challenge. Gennaio 04: inizio dc04.
L’INFN parecipa al 26%.
A fine Agosto:
9 milioni di eventi a Legnaro, 900000 a Bari, 300000 a Pisa (cmkin).
Cmsim 0.5M.
In totale circa 45M di eventi in 45 giorni. Bari Bologna e Padova dovrebbero avere finito i loro
100K eventi. CMKIN: fatti 64M di eventi su 69 assegnati. Tutte le ntuple sono state trasferite al
CNAF usando bbftp. CMSIM: 18Mfatti su 25M.
CMSIM 132 aveva un baco, ma gli eventi prodotti sono comunque ok.
CMSIM 133 è invece ok.
COBRA 7.5 è in fase di prerelease.
OSCAR: primi test di fisica fatti con 2_3_2_preX.
Domanda di Alessia: chi si è validato con CMSIM può iniziare con OSCAR o deve aspettare?
Simone risponde che Pisa ha iniziato con OSCAR senza aspettare nulla. Alessia risponde che Pisa è
un centro pilota. Il suggerimento è di chiedere a Barone.
OSCAR: versione 2.4 con prima versione COBRA 7.5
ORCA: 7.3 ok per la fisica, 7.4 in fase di prerelease, 7.5 sarà la versione usata per la produzione.
Tutti i centri sono validati per CMSIM eccetto: Padova, Torino, Perugia, Milano.
Trasferimenti:
SRB per trasferimenti CERN-CNAF ok.
Per lanciare CMSIM è necessario fare il download dal CNAF delle ntuple di CMKIN, a meno che
non le si abbia già in sede.
Da più parti si ritiene inaccettabile che i centri pronti a Luglio non facciano ancora nulla.
Vitaliano: il motivo principale per cui si è stati fermi ad Agosto è che all’inizio il CERN non voleva
che tutti i centri partecipassero a CMSIM. Si è rimandata la cosa. Si è arrivati a Settembre
essenzialmente senza chiedere alcuna assegnazione. Bisognerebbe fare delle pressioni perchè prima
possibile arrivino delle assegnazioni di CMSIM. La posizione di alcuni è di chiedere direttamente
delle assegnazioni di OSCAR. Questo è ok, però siccome non si sa bene quale sia la situazione di
OSCAR, sarebbe bene farsi assegnare degli eventi di CMSIM, anche solo qualche migliaio.
Bagliesi: è d’accordo.
Simone: il tool per scaricare le ntuple è una cosa aggirabile: a Pisa le ntuple sono state trasferite
tranquillamente con scp.
Vitaliano: il problema non è del CERN. Il CERN vede l’INFN come una cosa unica, le divisioni
interne non gli interessano. Siccome il problema è italiano, il tool di trasferimento diventa una cosa
importante, perchè tenere il bookkeeping a mano dei trasferimenti che avvengono diventa
impossibile. La risposta di Luciano è di aspettare la fine della CMS week. Ma sarebbe bene iniziare
a fare qualcosa.
Discussione sui canali di benchmark del physics TDR.
Palla: I canali sono già decisi per b e tau. La discussione è sugli altri 4 gruppi che finiranno nel
physics tdr. Le persone del b-tau continueranno ma è opportuno discutere degli altri 4 gruppi.
Bagliesi: le cose sui gruppi di fisica vanno avanti in modo disorganizzato.
Alessia: al momento tutti hanno dovuto mettere in seconda priorità gli impegni d fisica perchè
bisognava avviare la produzione di hardware.
Bagliesi: si dovrebbe fare come ai tempi del daq tdr: ci si dovrebbe dividere le cose.
Alessia: Ct mantiene l’impegno sulla parte di b-tau (ttH), e l’impegno su SUSY.
Tonelli: il DC044 non si farà nei tempi previsti. C’e’ una crisi di Grid. Lo steering committee
pensava addirittura di resettare tutto. Le stime più ottimiste sono di 6 mesi di ritardo perchè non c’è
nulla di pronto. Di sicuro gli eventi saranno pronti non prima della fine dell’estate 04. Quindi va
bene lavorare su queste cose, ma non occorre affrettarsi.
Stato delle analisi nelle varie sedi
Firenze (Carlo): Riccardo ha presentato a Luglio lo studio del rumore. Ha fatto una tabella con i
gain di tutti gli optohybrid che può essere messa in rete. Anna Macchiolo ha fatto uno studio
sull’isteresi che verrà presentato domani. Ora si può iniziare con la parte più interessante che è lo
studio temporale con il fascio a 25 ns.
Pisa (Fabrizio): sono stati fatti dei talk. Si sta facendo un’analisi sull’overlap (MariaRosaria). Lo
scopo è riuscire a trovare l’efficienza intrinseca del detector dal conteggio di singole e di doppie. E’
in programma lo studio dell’alta statistica, che era richiesto da Laura e Alberto. Sarebbe interessante
vedere come si comportano i rivelatori in condizioni di umidità diversa, dato che ci sono dei run in
condizioni di diversa umidità: tutti i run sono stati fatto con alta umidità tranne alcuni per i quali è
stato fatto flussare azoto fino ad arrivare ad umidità del 3-4%. Si vuole vedere come cambia il
rumore in condizioni di bassa umidità.
Discussione sulla Rapid Note sul test beam per conferenze
Katia deve presentare un talk ad una conferenza sul test beam. Ma secondo le nuove regole è
necessario avere una nota per poter andare a conferenze.
Fabrizio chiede se c’è l’idea di fare una Rapid Note nella comunità TIB per poter andare a
conferenza, che però deve essere seguita da una nota. La Rapid Note può contenere anche cose
banali (rumore, segnale su rumore, non ancora la parte sull’isteresi).
Rispetto al Test Beam precedente, si dovrebbero fare più note, invece che una sola grossa nota.
Carlo: che si debba scrivere la nota è fuori discussione. Bisogna solo vedere come siamo con i
tempi.
Tonelli: è impensabile scrivere una nota in una settimana, si dovrebbero fare le cose per bene.
La decisione è che si identifichino degli item da indicare a Katja (anche solo 3-4 slides) per quanto
riguarda la comunità TIB.
5 SETTEMBRE: CONSORZIO
Agenda:
09:00-09:05
09:05-09:30
09:30-09:55
09:55-10:20
10:20-10:45
10:45-11:15
11:15-11:40
11:40-12:05
12:05-12:30
Minutes and matter arising
Summary della riunione TISB
Tender del low/high voltage PSU
Ultimi moduli costruiti
Pianificazione costruzione moduli
Procedure e logistica di costruzione
New tool for module test
Isteresi sensori
Sensori ST
Rino
Giuseppe B.
Giuliano/Ettore
Bari/Pisa
Gianmario
Tutti
Suchandra
Anna
Alberto
Castaldi: le difficoltà al gruppo I sono ormai superate.
Meschini: Lino chiede se si può lanciare la produzione dele piastre da mettere nelle cold-box con lo
spessore modificato (lo spessore è stato abbassato di 3 mm). Marco chiede anche ai vari centri se
hanno registrato problemi con la cold-box. C’è ancora qualche piccolo problema (Dell’Orso segnala
che a volte il software si pianta e non si capisce perchè, De Palma segnala che a Bari hanno dovuto
cambiare il chiller), però in generale le cose vanno bene. Se ci sono dei problemi devono essere
segnalati a Wim.
Bagliesi: riassunto riunione TISB
Vedi minute TISB.
Tender del low/high voltage PSU (Castaldi-Focardi)
C’è stato un incontro tra Parrini e Sharp. Il tender allargato agli altri sottorivelatori è accettabile se
non danneggia il tracker. Dal punto di vista amministrativo non ci sono problemi. Dal punto di vista
tecnico la richiesta del tracker è che gli altri sottorivelatori siano pronti entro i tempi. Gli RPC sono
pronti, per gli altri non si sa. ECAL mostrava perplessità perchè a quel punto non è ben chiaro di chi
sia la responsabilità della gestione di questi moduli.
Ultimi moduli costruiti (My – Fiore – Dell’Orso)
My: testati 3 moduli (con ciclo termico), gli altri sono andati a Firenze e Torino. Uno dei quattro
rimasti a Bari è sotto osservazione perchè l’uscita di due chip non si vede. Questo problema è
venuto dopo l’assemblaggio.
Fiore: stato della produzione a Bari. Sono stati fatti 4 moduli al giorno dal 28 agosto al 3 settembre.
Il problema principale è che sembra che la macchina si stia rompendo: a volte si pianta durante il
processo e si deve ricominciare. Probabilmente c’è qualche problema hardware, qualche scheda si
sta rompendo. Non si riesce ad andare a regime di 8 mudoli al giorno, perchè già in queste
condizioni farne 4 è abbastanza dispendioso in termini di tempo. Chiamare i tecnici è onerosissimo,
perchè il contratto di manutenzione è molto alto. La proposta di Fiore è che si usi la macchina di
Padova che è stata poco usata, per capire quale possa essere il problema. Tonelli dice che la cosa è
importante, e non importa quanto sia onerosa la manutenzione, bisogna chiamarla perchè il
problema va risolto.
Fiore dice che anche in qualche altro centro si inizia ad evidenziare qualche piccolo problema.
Per la gantry c’è richiesta di personale: una persona a Perugia e una persona a Bari che vorrebbero
dei fondi (degli articoli 2222). Tonelli dice che c’è l’accordo con Catania, e Bari dovrebbe prendere
un tecnico da Catania.
Dell’Orso: Bonding e Test dei primi 4 moduli a Pisa.
Shipping e receving ok. Ispezione ottica ok. Il test ARC in futuro sarà fatto direttamente dal tecnico
che fa il bonding.
Curva IV: se l’umidità è al di sotto del 50% la curva è buona, altrimenti la corrente è anche doppia.
E’ necessaria una flow-box per svincolarsi dall’umidità ambientale.
Bonding: L’informazione dei 4 moduli è stata inserita nel database di produzione. Il pulltest non è
completamente soddisfacente ed è dispendioso in termini di tempo. Focardi dice di fare il pulltest
solo sui pitch adapter d’ora in poi.
I test ARC vanno bene. Si è usata la 6.2 che crea anche le quality flag. Però sono stati trovati alcuni
problemi: i tagli dei file sono stati ottimizzati per i TOB. Una volta risolto questo problema si
possono inserire i dai nel db di produzione. Meschini dice che nel db di produzione non ci sono
ancora le tabelle, però una volta provato nel db di test non ci dovrebbero essere problemi.
La pagina di Salvatore Costa è utilissima perchè dà un riassunto della produzione.
LT test con ciclo termico: si è riuscito a fare tutto automatizzato, e tutto va correttamente anche se
in alcuni casi il programma si inchioda e non si è ben capito perchè. La Vienna box non è del tutto a
tenuta. Roberto pone la questione se sia il caso di fare il LT davvero a -20°C, perchè ci sono
problemi. Meschini dice che è stato deciso così e dovrebbe farsi così, per stressarli bene e anche
perchè i -20 si riferiscono alle piastre fredde, ma a -20 è possibile che i moduli siano a -10, e se si
mettono le piastre fredde a -10 c’è il rischi che i moduli siano a temperature più alte..
Quindi in linea di massima la procedura di produzione va bene e ci sono solo dei dettagli da
sistemare (tagli di ARC 6.2...).
Un problema che ha Pisa è che hanno due schede ARC ma una sola scheda LED e se si rompe si
rischia di fermare le cose.
Pianificazione costruzione moduli (Bilei)
Il problema della resistività dei sensori Hamamatsu è stato risolto. Consegnati 2300 sensori su
6800. I test a campione sono in corso.
Pitc adapter: la produzione è stata avviata a marzo. A settembre dovrebbe essere completata.
Per i frame stiamo seguendo bene i tempi previsti. Tutto va bene per i single sided. Non ci sono
problemi nel continuare l’assemblaggio alla Sensystem. Per i double sided siamo in ritardo.
Per gli ibridi siamo messi meglio degli altri.
Costruzione moduli: 10 SS costruiti a luglio, 96 in costruzione, dovrebbero essere pronti per il 25
settembre. Meschini dice che è impossibile che per quella data siano anche testati tutti. Si possono
testare a campione, ma non siamo ancora in grado di testarli a lungo termine in poco tempo.
Tonelli dice che stiamo cercando tutti di stressare il sistema per fare le cose previste in tempi
previsti, ed è necessario che anche il module test dia una data a breve alla quale ci si possa
considerare a regime, altrimenti si potrebbe aprire una crisi.
Meschini dice che si aspetta che per fine ottobre la cosa si potrà stabilizzare.
Tonelli chiede dove si può fare il test di LT di singolo modulo: rispondono Torino e Pisa. Bari,
Firenze, Padova e Catania non l’hanno mai fatto ma non sono lontani e potrebbero farlo a breve.
Si decide che per il momento l’obiettivo è fare per 4 giorni due moduli e per due giorni 4 moduli al
giorno.
New tool for module test (Suchandra)
Suchandra mostra un nuovo tool per il module test sviluppato a Pisa.
Prende root files da tutti i client. C’è un check visivo veloce delle strisce cattive. E’ in grado di
plottare velocemente noise, calibration profile ecc.
Isteresi nei dati del test-beam (Macchiolo)
Durante il test-beam di maggio sono stati effettuati diversi scan in tensione. Si osserva un fenomeno
di isteresi, cioè il rapporto S/N dipende dal ciclo di tensione a cui il modulo è stato sottoposto
precedentemente.
In uno scenario standard (tensione da 0 a quella di lavoro) si ritrovano le performance attese sia per
i TIB che per i TOB. Nel ramp-down le cose vanno diversamente, con un deterioramento del S/N
alla stessa tensione. Questo comportamento si vede sia in picco che in deconvoluzione.
Questo viene sia da un abbassamento del segnale che da un aumento del rumore. Abbassando la
tensione di polarizzazione aumenta la larghezza del cluster, mentre il numero di cluster rimane
invariato.
In deconvoluzione a 300 V: il segnale diminuisce del 8% il rumore aumenta del 7%, il S/N
diminuisce del 17%.
Per i moduli TOB in deconvoluzione non si osserva l’effetto di isteresi. L’aumento della larghezza
del cluster e del rumore può essere dovuto all’aumento della capacità inetrstrip dei sensori.
In laboratorio sono state studiate le C-int di sensori Hamamatsu ripetendo cali di tensione simili a
quelli che possono esserci in testbeam. La capacità interstrip cresce facendo cicli di tensione. Di
quanto cambia è legato a vari effetti: a quanto il sensore viene tenuto ad un valore di tensione. Si è
misurato come varia la C-int nel tempo mantenendo la tensione costante. A 250 V, dopo circa
un’ora ritorna alle condizioni iniziali.
Sulle strutture ST non si osserva l’effetto di isteresi. Però si sapeva già che nei sensori Hamamatsu
la C-int diminuisce se il substrato è portato ad alta tensione in condizioni di alta umidità. Si sono
fatti allora degli scan al 4% di umidità. Negli hamamatsu a bassa umidità l’isteresi scompare e ciò è
confermato anche da alcune misure che sono state fatte a Strasburgo.
Un’altra prova fatta è stata testare con ARC il rumore. Ad alta umidità si ritrova l’effetto di isteresi,
e non si vede più a bassa umidità.
Alla fine sembra che con umidtà al di sotto del 35% si dovrebbe essere tranquilli.
Situazione sensori ST (Messineo)
I ritardi nella consegna non sono dovuti all’ST, ma alla gestione del CERN.
I sensori ricevuti sono sati processati con il processo standard. Il processo è iniziato in Febbraio
2003. In settembre dovrebbero essere ricevuti dei batch per la nuova modalità di processo.
Per ciò che riguarda la qualifica dell’ST siamo completi, tutte le misure sono state fatte. La
reiezione dei sensori dalla IV per l’ST è del 18%, che per loro è accettabile: non sono previsti
ulteriori miglioramenti. La produzione di Luglio conferma il successo nel tuning del polisilicio. Il
problema della tensione di flat band è stato risolto.
Massimiliano Chiorboli