1. 1 Laser Monitoring in ECAL DB Toyoko Orimoto ECAL Databases Meeting 18 September 2007 Status of ECAL laser objects Performance improvements Next steps

2. 2 Laser (Offline) Database Records CondFormats/EcalObjects Three objects required for laser transparency correction: EcalLaserAlphas EcalLaserAPDPNRatiosRef EcalLaserAPDPNRatios: APD/PN pairs and time stamp pairs Beginning with 1_6_0_pre7 Note: means we had to delete all of our pre-existing database tables, because these tables were made with old maps to uint32_t… struct EcalLaserTimeStamp{ uint32_t t1; uint32_t t2; }; struct EcalLaserTimeStamp{ edm::Timestamp t1; edm::Timestamp t2; }; uint32_t changed to edm::Timestamp format to be consistent with what is expected for Monte Carlo

3. 3 Performance Improvements Efforts in ECAL software side to optimize performance, including DB aspects Performance with laser correction in 1_6_0 Time to make the calib RecHits for each event increased by x4 (with trivial conditions, ie no real database access) EcalRecHitProducer w/o vs w/ correction: 0.8 msec  ~3 msec Increase due to maps used for accessing records… (?) typedef std::map EcalLaserAlphaMap; typedef std::map ::const_iterator EcalLaserAlphaMapIterator; Each value associated with one xtal via DetId std::map is very time-consuming and should be avoided During database access *and* during reconstruction Move to use std::vector instead of std::map

4. 4 Changes for std::map to std::vector Summary of min. changes to migrate from maps to vectors: typedef in CondFormats/EcalObjects/interface constructor in CondFormats/EcalObjects/src to initialize size of vector (to total number of xtal hashedIndex’s) Dictionary classes in CondFormats/EcalObjects/src/classes.h and CondFormats/EcalObjects/src/classes_def.xml Trivial cond retriever in CalibCalorimetry/EcalTrivialCondModules Use hashedIndex() to associate DetId with position in vector New tool in EcalDetId to monotonically number xtals EB: xtal index (1 to 1700) + (1700 * iSM) EE: increases in rows ix and iy, with “hole” mapped Change find() methods to use vectors with hashed index alpha = laserAlphaMap[hi]; hi = EBDetId(xid).hashedIndex(); // EB case hi = EEDetId(xid).hashedIndex() + EBDetId::MAX_HASH + 1 // EE case

5. 5 Performance Improvement Results Changes completed, tested, and committed for laser records Tested fully: Read/write from a local sqlite file and ORCOFF (cms_ecal_off_test) in cms_orcoff_int2r. Ecal trivial conditions & laser correction module OK Changes committed to HEAD for CondFormats/EcalObjects CalibCalorimetry/EcalTrivialCondModules CalibCalorimetry/EcalLaserCorrection CondTools/Ecal Performance checked with old maps vs. new vectors: Generated and reco'd small sample of events with Configuration/ReleaseValidation with trivial conditions Checked the CPU usage reported by TimeModule for EcalRecHitProducer in 1_7_0_pre1 Before: 3.9ms --> After: 1.9ms (~50% improvement)

6. 6 Next steps Laser database values for CSA07 One payload with runnumber IOV from 1 until endOfTime Will produce a “trivial” laser correction factor of 1 Laser database values for testing in 1_7_0 Will be a real test of payload/IOV Need runnumbers/timestamps in MC so we can properly define IOV and APD/PN timestamp values O2O We would like to implement corrections to our laser data during the O2O process (Jan Veverka) Is POPCON the right thing to look to for this? Just getting started, much to learn…

7. 7 Summary Efforts to improve performance Changes completed, tested, and committed to migrate from maps to vectors for laser database objects Thanks to Federico, Francesca, Vladlen, Zhen, for help Next to fill DB for CSA07 and testing of 170 code Then focus on moving on to online and O2O issues for laser monitoring