1 / 11

Laser Monitoring: Databases and Offline Transparency Correction in CMSSW

Toyoko Orimoto Caltech 02 Aug 2007. Laser Monitoring: Databases and Offline Transparency Correction in CMSSW. 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

maren
Download Presentation

Laser Monitoring: Databases and Offline Transparency Correction in CMSSW

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. Toyoko Orimoto Caltech 02 Aug 2007 Laser Monitoring: Databases and Offline Transparency Correctionin CMSSW

  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. The General “Offline” Picture Event ORCOFF Database EcalRecHitsProducer EcalObjects EcalLaserAPDPNRatios SQLITE EcalLaserCorrectionService EcalLaserAPDPNRatiosRef EcalLaserAlphas EcalTrivial CondModules EcalLaserDbService Transparency Correction

  4. struct EcalLaserTimeStamp{ uint32_t t1; uint32_t t2; }; struct EcalLaserTimeStamp{ edm::Timestamp t1; edm::Timestamp t2; }; 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

  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 ORCOFF DB Event Setup EcalLaserDbService EcalLaserCorrectionService Event Transparency Correction

  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. 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) • 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! Row Run event timeHigh timeLow ----- ----- ------ ----------- ----------- 0 50001527 1 0 5000000 1 50001527 2 0 10000000 2 50001527 3 0 15000000 … 998 50001527 999 1 700032704 999 50001527 1000 1 705032704 1000 50001554 1 0 5000000 1001 50001554 2 0 10000000 1002 50001554 3 0 150000000

  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. 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. 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. 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

More Related