Status of LArG Reconstruction Softwares

1. Status of LArG Reconstruction Softwares Data flow in the LArG Reconstruction software chain Updated status for various reconstruction algorithm LAr Converters and miscellaneous Plans Kin Yip

2. LArHit LArDigit LArRawChannel LArCell LArCnv LArDigitization LArROD LArCellRec Here, you can run Egamma, MissET and/or other algorithms … CaloTower LArCluster CaloRec LArClusterRec If you wonder, colour here after all is meaningless. Data flow in LArG software reconstruction

3. MC: LArDigitization LArHitZebraCnv LArROD LArTBCnv (LArHECTBCnv) TB: Status of LArG reconstruction algorithms In MC mode : • LArHitZebraCnv produces LArHit Object • LArDigitization is reading in an ascii file for the characteristics of the channels such as waveforms, noises, pedestals, to create ADC’s for each channel • Missing the accompanying calibration constants for LArROD In TestBeam mode, LArTBCnv/LArHECTBCnv produces “LArDigit-like” objects directly.

4. ROD FEB LArDigit (ADC's) LArRawChannel (E, T, 2) LArROD • The task is to convert ADC counts of several samples stored in the LArDigit to energies, times and 2’s • ADCi = ADCi – pedestali • Energy E=  aiADCi • Time T = (biADCi) / E • Quality 2= ADCi - (giEgi'ET) 2 • where ai,biare the optimal filtering constants (OFC’s)and gi, gi'are the waveforms

5. Status of LArG reconstruction algorithms (cont.) • In MC, LArROD right now is still using a fixed set of calibration constants • In TB, LArROD makes use of the package “LArConditions” to get various calibration constants from (MYSQL) database — probably a temporary solution. • The requested data from the database are loaded into the memory at the initialization stage of “LArConditions” • During run time, LArROD uses various LArConditions methods to retrieve the necessary information from the memory, eg. • m_sql  set_gain(igain) • m_sql  getOFC_a(, , tbin) • m_sql  getPedestal(, , tbin)

6. TestBeam Energy from the LArROD Run 208850 (year 2000), Beam energy at 99 GeV, =3, =10 Energies of the particular one cell at =3, =10 (middle layer) using med. gain • No cuts of run/trigger/beam-chamber information have been made (partly because they are not easily available from LArTBCnv) • with the necessary “adcgev” conversion factors applied

7. Status of LArG reconstruction algorithms (cont.) • Convertersare used upon request to create “data objects” in Transident Data Store (TDS) from persistent input, and also write data objects in TDS to persistent output. • For input, we can read in data in the formats of Zebra (LArHitZebraCnv) and Objectivity (LArNaiveObjy) • For output, we can write out data in the formats of Objectivity (LArNaiveObjy) and Root (LArAthenaRoot). • LArNaiveObjy is probably an intermediate solution until ADL comes along • LArNaiveObjy in CVS but not in the release; but LArAthenaRoot is in the release • Container package for LAr Converters are in general in LArCalorimeter/LArCnv

8. Status of LArG reconstruction algorithms (cont.) • LArSim provides the base classes for various “LArCnv pacakges” to produce LArHit objects. • Recently, there is a new species of “LArHit” in LArSim called LArCompactHit. • It uses 32 bit LArHardwareID’s in data members instead of the “identifier” • The purpose is to save memory space for Pileup data • Its interface is similar to other LArHit species and can be used to replace them. • LArHardwareID is in detector channels such as feedthrough no., FEB slot etc. • complete for the entire barrel region but still missing for the end-cap and forward regions • LArCellRec & LArClusterRec have been working for a long time • CaloRec has put LAr cluster information to the standard CBNT ntuple

9. Plans in the next 6 months to one year • We are in the process of developing a master plan for actions over the next year • Need more people to get involved, esp. from HEC • Architecture issues • Implementation of const-access policy • Package re-organization/Dependency Issues • Algorithm, Data and Helper Class packages • Data Objects • Implementation of ADL supported data classes • Persistency support for intermediate objects (CaloCell, CaloCluster etc.) • Implementation of DataLinks for persistable inter-object relationship • Use of detector store to obtain Detector and Conditions information • ATLFAST parameterization to produce CaloCell (LArCell) Not in the order of priorities

10. Plans in the next 6 months to one year (cont.) • Offline reconstruction • Revisit reconstruction design issues • Revisit and implement new calorimeter corrections derived from using updated geometry • Revisit clustering algorithms; implement and study new algorithms such as nearest neighbour algorithm • Use of new software for detector/physics studies  feedback on reco • Performance studies/optimizations • Effects of too many LArCell objects • Event Filter support: Byte stream and Performance issues • Digitization and ROD • LArDigitization/LArROD for Endcap/Hadronic • Need database support for description of waveform, noise and OFC’s • HardwareID definitions and mapping for HEC • Pile-up effects in Athena (waiting for the “framework” group to provide the mechanism) • New package: zero-suppresion in Athena to handle and study zero-suppresion offline