1 / 12

ORCA Calorimetry Software Status and Plans

This document outlines the current structure and upcoming changes in ORCA Calorimetry Software, detailing storage and access methods, new data organization, and challenges. It also discusses user needs, dependencies, and updates for different components. Additionally, it covers user requests, like Fermilab JetMet and LPC, and issues with EcalPlusHcalTowers navigation. The post touches on calibration, ECAL, HCAL, and CASTOR geometry developments.

jeffwitt
Download Presentation

ORCA Calorimetry Software Status and Plans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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: HcalBase EcalBarrelBase EcalEndcapBase PreshBase CaloBase Represents a subsystem 1 ~10,000 Indexed by integer CellProperties

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

  4. How the data is stored and accessed now CellProperties PRecDet of CaloDataFrames CaloDataFrame CaloDataFrame CaloDataFrame … CellProperties CaloBase CellProperties 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 CaloDetUnit Slave Readout Master Readout CaloDetUnit Slave Readout CaloBase CaloDetUnit Slave Readout CaloDetUnit Slave 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)

  6. Master Readouts Master Readout CaloDetUnit Slave Readout CaloDetUnit Slave Readout CaloBase CaloDetUnit Slave Readout Master Readout CaloDetUnit Slave 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 = 40o sectors in f, plus 3 for each HF • Still need to implement for ECAL, preshower

  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 CaloDataFrame CaloDataFrame getMyCell() Implicitly converts Back and forth CaloBase CellID PCellID 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? CaloBase CellID CaloDetector CaloDetUnit CaloDetUnit CaloReadout Cannot implicitly Convert PCellID to CellID! CaloDataFrame CaloDataFrame BROKENINTERFACE! frame.getMyCell() becomes, CellID(frame.getMyCell()) CaloCommon PCellID

  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

More Related