1. ORCA Calorimetry Software Status and Plans ORCA Core Calo group: Rick Wilkinson Andre Holzner Homer Neal Nov. 29, 2004

2. The way the geometry is currently organized: CaloBase CellProperties Represents a subsystem Indexed by integer HcalBaseEcalBarrelBaseEcalEndcapBasePreshBase 1 ~10,000

3. The way the geometry will soon be organized: CaloBase CellProperties Represents a subsystem Indexed by integer HcalBaseEcalBarrelBaseEcalEndcapBasePreshBase CaloDetType CaloDetUnit Info common to all cells in this subdetector 1 ~10,000

4. How the data is stored and accessed now CaloBase CellProperties PRecDet of CaloDataFrames CaloDataFrame … CellProperties User needs to loop over all data frames, find the cell index inside the data frame, And match it to the index of the cell in the CaloBase. CaloHits, CaloDataFrames, & CaloRecHits all do this.

5. How the data will be stored and accessed CaloBase Master Readout Each slave has a data cache, which means each CaloDetUnit holds its own data Master Readout handles persistency: stores the data in one big container fills the slaves when it reads data in. For CaloHits, the class is called “CaloSimDet” (implemented, not released) For CaloDataFrames, the class is called “CaloReadout” (implemented, not released) For CaloRecHits, “MasterRecDet” (implementing now) Slave ReadoutCaloDetUnit Slave Readout

6. Master Readouts CaloBase Master Readout We’re free to associate the SlaveReadouts with any MasterReadout we choose We might as well make a realistic DAQ configuration Currently, for HCAL, we’re using one readout = 40 o sectors in  plus 3 for each HF Still need to implement for ECAL, preshower Slave ReadoutCaloDetUnit Slave Readout Master Readout

7. Complications: Different Mechanisms for hits, digis, & rec hits Backwards-compatibility –Need to be able to always read DC04 datasets. –Data format goes from SimpleRawData to HashedRawData Gains integer index –Good time to change names: CHEBRY01 -> CaloHitsEcalBarrel01 Solution requires: –Reading & writing SimpleRawData in Master/Slave readouts Requires lots of copied code to make custom versions of HitLoaders, DetCarfROU, and MasterRecDets. Environmental variables control which one is instantiated. –CaloItrs and CaloHitItrs that don’t break interfaces Andre was able to specialize templates, inside namespaces –More testing scripts! Lots of combinations of reading & writing from old & new readouts, and with & without selective readout

8. Dependencies: Old code PCellID CellID Implicitly converts Back and forth CaloBase CaloDataFrame getMyCell() CaloDataFrame CaloDetector CaloDetector cannot “know about” CaloDataFrames In other subsystems the detector knows about the data The data does not know about the detector

9. Dependencies: New Code? PCellID CellIDCaloBase frame.getMyCell() becomes, CellID(frame.getMyCell()) CaloDetector CaloDataFrame CaloDetUnit CaloReadout CaloDetUnit Cannot implicitly Convert PCellID to CellID! BROKEN INTERFACE BROKEN INTERFACE! CaloCommon

10. Calo/CommonDet Status SimHits : Implemented, not released Digis : Recently made backwards-compatible –Looks good, but still need more testing RecHits : Not done yet DetLayers : Not done yet Lots of other little changes piling up in the CVS Head Refactoring geometry Refactoring digitization & zero-suppression Reorganize BuildFile

11. User Requests: Fermilab JetMet LPC EcalPlusHcalTowers: –Problem: Even simple tasks like finding a neighboring tower are slow and cumbersome: –No easy way to find the HCAL cell associated with the EcalPlusHcalTower. –Then need to find the neighboring HCAL cell, and then loop over every Tower in the RecCollection to find the one they want. –Solution: Made a utility class (EcalPlusHcalTowerBase) which stored the towers in a map, and performs operations like ET-sorting, and returning towers within a cone or square. –Problem: Navigation. cells in stored in a map, indexed on a packed Cell ID. Accessed through north-south-east-west methods –They think it would be both faster and more intuitive to store the cells in a grid array. Allows direct lookup: no map searching. A little complicated because of changing phi granularity, but seems reasonable –But not right now Users of CaloRecHits (e/gamma) may want similar things.

12. Other issues Calibration: In touch with testbeam groups, prototyping code –ECAL: Andre –HCAL: Rick CASTOR geometry: Homer