From spagnolo@le.infn.it Mon Nov 12 09:25:25 2007 Date: Fri, 9 Nov 2007 18:34:57 +0100 (CET) From: Stefania Spagnolo To: Michela Biglietti Cc: "Stefania.Spagnolo@le.infn.it" , Gabriella Cataldi , Diana Scannicchio , Gabriele Chiodini Subject: Re: EF ID Ciao Michela e tutte, includo Gabriele che e` interessato a tutta la faccenda dei converters RPC e ha studiato parecchio il codice attuale. Ho letto solo ora con attenzione questo mail e mi pare che lo schema usato dall'ID a livello di filtro e` esattamente quello che stavamo prefigurando: - uso del cnv BS->RDO su base di una selezione di collections (non su tutto), secondo una lista di identifiers fornita dal region selector - uso di un tool per convertire gli RDO ottenuti in Collections di PRD (che sono identifiable anche quelle !!!) Questo ci garantisce che al nostro approccio non dovrebbero essere avanzate obiezioni di principio... Ciao, Stefania On Thu, 8 Nov 2007, Michela Biglietti wrote: > Date: Thu, 08 Nov 2007 17:45:24 +0100 > From: Michela Biglietti > To: "Stefania.Spagnolo@le.infn.it" , > Gabriella Cataldi , > Diana Scannicchio > Subject: EF ID > > Ciao Stefania e tutte, > > alla fine John mi ha consigliato di parlare con Jiri Masik che mi ha > spiegato le seguenti cose : > guardate per esempio > > http://atlas-sw.cern.ch/cgi-bin/viewcvs-atlas.cgi/offline/InnerDetector/InDetTrigRecAlgs/InDetTrigPrepRawDataFormat/src/Pixel_TrgClusterization.cxx?revision=1.58&view=markup > > questo è un algoritmo HLT tipo FEX in cui loro : > > 1. fanno il retrieve da SG del container PixelRDO_Container > 2. usano il regionselector per ottenere gli id delle collezioni, tramite > il metodo > indexFind() ottengono le collezioni vere e proprie: > > PixelRDO_Container::const_iterator > RDO_collection_iter = p_pixelRDOContainer->indexFind(m_listOfPixIds[i]); > > > Questi due step sono uguali a noi : la differenza è che loro hanno un > converter BS, > > InnerDetector/InDetEventCnv/InDetRawDataByteStreamCnv > > che contiene sia la codifica che la decodifica. > Per cui indexFind() equivale a richiedere e convertire solo le > collezioni desiderate. > Jiri mi diceva che ha stimato ~10 ms per collection, e che vorrebbero > ottimizzare. > > Il formato dati in input di LVL2 e EF è lo stesso ma il LVL2 non usa > gli stessi converter BS che usa il filtro ma una roba ottimizzata, > pero' non mi ha saputo dare molti dettagli. Probabilmente anche li > usano qualche informazione tipo il cablaggio. > > Gli ho chiesto cosa ci fanno con gli RDO che ottengono via indexFind() e > mi ha detto che utilizzano > dei tool per trasformarli in collezioni di cluster > > m_clusterCollection = > m_clusteringTool->clusterize(*RDO_Collection,*m_manager,*m_idHelper); > > che (notare bene) vengono messi successivamente in SG come identifiable > containers per cui ci possono usare su di nuovo il RS, per esempio. > > Ognuno tragga le proprie conclusioni ... la mia è che forse vale la pena > tentare la soluzione di > fare un algoritmo in sequenza HLT che fa la stessa cosa che fa l'ID con > le sostituizioni : > > PixelRDOCollection --> MuonRDOCollection > PixelClusterCollection --> Muon PRD > > e girare successivamente TrigMoore cosi com'è. Questo implica che gli > algoritmi RDO-->PRD vengano > trasformati in tool (tanto per cambiare). > Salvo poi misurare tempi e memoria e decidere che va bene. > Fatemi sapere, michela > > > > > > ------------------------------------------------------------------------- Stefania Spagnolo Dip. di Fisica, Univ. di Lecce / +39 0832 297458 (office) 297569 (lab) INFN Lecce / +39 0832 325128 (fax) -------------------------------------------------------------------------