Calorimetry code: recent changes and future plans

1
Calorimetry code recent changes and future plans
André Holzner ETHZ Vladimir Litvin CALTECH
CMS RPROM Meeting, May 19, 2003
2
DDD support of Calorimetry

• For the next ORCA Release (ORCA 7.2.0)
• new .orcarc datacards ECAL Barrel
  EBRYGeomSource DDD or G3 ECAL Endcap
  EFRYGeomSource DDD or G3 HCAL
  HCALGeomSource DDD or G3
• Default is still G3 geometry
• So far, only 'simplified' geometry is supported
  with DDD (code issues a warning and reverts to
  simplified if 'detailed' is selected)
• the geometry level defaults to 'simplified'

3
DDD support of Calorimetry

• Ecal Trigger tower coordinates are now calculated
  from the crystal coordinates (i.e. no additional
  G3/DDD datacard)
• Still to be done Defining an DDD format for the
  Ecal endcap crystal-to-trigger tower association
  (currently a separate file)
• CMS note of changes being finalized

4
Future Plans (I)

• Simplifying the Bases
• move as much 'similar' code as possible to
  CaloBase
• Organize them similarly to Tracker, e.g. cell
  navigation
• Have consistency between OSCAR and ORCA
• Move code related to Calo cell numbering scheme
  and hit writing/reading to COBRA/Profound
  (instead of copying code)

5
Future Plans (II)

• Example go from NUMBV indices to CellID and
  module/crystal indexes
• currently
• EcalEndcapMakeID(const vectorltintgt numbv)
• EcalEndcapunpackindex(const unsigned idx,
• int z, int module, int crystal)
• future
• CellID cell CellIDmakeCellID(const
  vectorltintgt numbv)
• cell-gtGetPackedIndex()
• CellIDEcalEndcapGetZIndex()

6
Future Plans (III)

• Need to talk to some OSCAR/Calo expert to find
  out what functionality is actually needed in
  OSCAR(e.g. why does one need bases etc.)
• Calculation of neighbours for Navigation at time
  of setting geometry, storing the neighbours in a
  map or a hash_map
• Not clear though whether this will significantly
  increase speed...
• Further changes suggested by Bart van de Vyver...

7
Future Plans (IV)

• First prototype version of redesigned Calorimetry
  is in progress. There are two main points
• To make Calorimetry more modular. Starting from
  one ROU per one Cell. Real hardware
  implementation of ROU will be later on. We need
  DDD description of hardware ROU to finalize this
  (this is absence now).
• To speedup the Calorimetry. Some profiling
  activity will be done after redesign.
• Tracker and Muon will be heavily reused.

8
Schedule

• now numbering scheme
• May/June Redesign (in the spirit of the
  tracker/muon code)
• First rough prototype by June CMS week
• June/July Testing and profiling
• Documented in another CMS note