1. 1 Laser Monitoring: Databases and Offline Transparency Correction in CMSSW Toyoko Orimoto Caltech 02 Aug 2007

2. 2 CSA07 & CMSSW_1_6_0 We’re in! Code for offline database records and offline transparency correction will be in 1_6_0, for CSA07 Calibration Exercise Developed and tested for 1_6_0_pre6: V00-02-00 CondCore/EcalPlugins V00-07-04 CondFormats/EcalObjects V00-01-01 CalibCalorimetry/EcalLaserCorrection V00-10-01 CalibCalorimetry/EcalTrivialCondModules V02-02-00 CalibCalorimetry/Configuration V00-10-00 RecoLocalCalo/EcalRecProducers The overall structure of things has not changed since our last meeting, though many of the details have been filled in.. Will discuss some of these details and outstanding issues in the next slides… Database objects Offline correction “Trivial” values Calib. RecHits

3. 3 EcalObjects The General “Offline” Picture EcalLaserCorrectionService Event EcalLaserDbService EcalRecHitsProducer EcalLaserAPDPNRatios EcalLaserAPDPNRatiosRef EcalLaserAlphas ORCOFF Database SQLITE EcalTrivial CondModules

4. 4 Laser Database Records CondFormats/EcalObjects Essentially the same as before, but change in timestamp format, which I will describe more later EcalLaserAlphas EcalLaserAPDPNRatiosRef EcalLaserAPDPNRatios uint32_t changed to edm::Timestamp format to be consistent with what is expected for Monte Carlo This means we had to delete all of our pre-existing database tables, because these tables were made with old maps to uint32_t… Otherwise we couldn’t write to the same DB --> OK, we can remake struct EcalLaserTimeStamp{ uint32_t t1; uint32_t t2; }; struct EcalLaserTimeStamp{ edm::Timestamp t1; edm::Timestamp t2; };

5. 5 Offline Transparency Correction CalibCalorimetry/EcalLaserCorrection EcalLaserDbRecord: Dependent record to hold Ecal Laser DB records EcalLaserDbService: Given pointers to DB records (alpha, APD/PN, timestamps, etc) + xtal DetId + Timestamp of event will compute the transparency correction Interpolation using two EcalLaserTimeStamp values Outputs multiplicative correction factor EcalLaserCorrectionService: ESProducer which will access the database and produce the values for alpha, reference, APD/PN ratios and timestamps Will produce new values for every update in IOV EcalLaserCorrectionService Event EcalLaserDbService Event Setup Transparency Correction ORCOFF DB

6. 6 Offline Transparency Correction (II) CalibCalorimetry/EcalTrivialCondModules Provides “trivial conditions”, ie, values for records without actually accessing the database By default, gives APD/PN = (1,1), APD/PN_ref = 1, alpha=1.55, TimeStamps are (1, “endOfTime”) CalibCalorimetry/Configuration/data/Ecal_FakeConditions.cff CSA07 Exercise should also test database access/load Will need to fill offline DB with values to give “null” corrections (ie, non-changing APD/PN values), similar to “trivial conditions” Fill with timestamps which correspond with values in MC Will also need to be careful of how we define the IOVs for the DB records.. If the IOVs don’t “match” well with what is in MC, then it will not test the database load properly.. Also, can define IOV by timestamp or by runnumber

7. 7 Timestamps in Monte Carlo Official time format in CMSSW is Timestamp DataFormats/Provenance/interface/Timestamp.h Essentially two 32-bit numbers (unsigned int): timeLow & timeHigh: A while back, timestamps in MC were nonsensical, but we’ve been promised “meaningful” timestamps in CSA07 MC For instance looking at sample from official production: /DrellYan_ll_10-40/CMSSW_1_4_4-CSA07-2059/GEN-SIM (Total, 4k events) RowRuneventtimeHightimeLow -------------------------------------- 050001527105000000 1500015272010000000 2500015273015000000 … 998500015279991700032704 9995000152710001705032704 100050001554105000000 1001500015542010000000 10025000155430150000000 You see that timeLow is increasing incrementally with each event However, It appears that for this particular sample, timestamp is unique only with *each run* --> If this is case, will use IOVs defined by runnumber rather than timestamp!

8. 8 Preliminary Testing & Performance RecoLocalCalo/EcalRecProducers Laser correction is compute “on the fly” for every RecHit.. Very basic testing: producing and reconstructing samples of 10 “single neutrino gun” events using trivial conditions Checked reconstructed energy before correction, with null correction, with non-null correction --> everything checks out. Will do more detailed testing: must be careful since this correction will be applied to every calibrated RecHit… Performance Time to make the calib RecHits for each event increased by factor of 4 (with trivial conditions, ie no real database access) EcalRecHitProducer: Without  With laser correction: 0.0008 sec  0.003 sec Increase in time perhaps largely due to maps used for accessing DB records… These will eventually be changed to linear vectors. Will try to improve performance Regardless, these are just milliseconds we are talking about…

9. 9 Light Monitoring Module Numbering Mentioned last time: need to map crystals light monitoring modules because we plan to store only one timestamp per light monitoring module For now, I’ve hardcoded a mapping for EB and EE in EcalLaserCorrection::EcalLaserDBService However, a more appropriate place: Geometry/EcalMapping: deals with electronics mapping for ECAL Thanks to Emmanuelle Perez, the mapping that I described last meeting is now in this package Tag: V00-00-12, will be in 1_7_X For future: EcalLaserCorrection in 1_6_X uses the hardcoded internal mapping, but for next update will use this new mapping NB: this is important not just for offline correction code, but also in future for database code, DQM, etc etc…

10. 10 Next Steps Further testing: reconstruction with corrections computed from database.. Determining values to place in the official CSA07 database: main issue is timestamps Utilizing the new light-monitoring mapping in Geometry/EcalMapping Performance issues: try to improve, if possible Any such improvements will go into 1_7_X THE END

11. 11 One detail: Mapping of Light Monitoring Modules In Offline DB, store timestamps according to light monitoring modules, so we don’t have duplication of numbers In EB, straightforward correspondence between SM, DCC, and Light Monitoring Module. In EE, there are two monitoring regions which are read out by two DCCs.. (see picture) In total for the EB+EE: 54 DCCs, 88 LMs and 92 LM readout. So we propose this numbering scheme: Geometry/EcalMapping: deals with electronics mapping for ECAL One caveat: ECAL DQM numbers things from EE->EB->EB->EE DCCLM LM- readout EB-10-271-36 EB+28-4537-72 EE-1-973-8073-82 EE+46-5481-8883-92