-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement ECAL rechits on GPU #462
Implement ECAL rechits on GPU #462
Conversation
Fix compilation warnings, remove commented out code, and apply code formatting rules.
// Then only if the LS is different, update the laser correction | ||
// The variation within a LS is not worth pursuing (<< 0.1% !!) | ||
// and below the precision we can claim on the laser corrections (right?). | ||
// This will save quite some time (also for the CPU version?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do the corrections actually change within a lumisection ?
or rather, does the interpolation has a granularity smaller than the lumisection ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current correction is based on "time". Namely, we have two measurements, one every 40 minutes, and we perform a linear interpolation among them.
Based on the code I would say that the correction is really time dependent, time of the event.
float interpolatedLaserResponse = p_i / apdpnref + float(tt - t_i) * (p_f - p_i) / (apdpnref * float(t_f - t_i));
One possibility (just an idea) to speed up is to calculate the correction once every LS. From physics point of view, this should have ~ no effect (24 seconds step function vs linear interpolation that extend 40 minutes), but it can be tested with the current available data.
Computationally wise, this could save some time.
To be discussed with who wrote in first place the interpolation code to see if there is something subtle I am missing (special cases).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like a very good idea !
(I always assumed the corrections were LS-based and handled by the EventSetup... this shows how far one can be wrong with reasonable assumptions)
Validation plots attached. In the following energy and chi2 for the rechits reconstructed in both cpu and gpu. NB: there are some cases where gpu is not reconstructed, coming from recovered channels. I am investigating the few outliers. |
RecoLocalCalo/EcalRecAlgos/bin/makeEcalMultifitResultsGpuValidationPlots.cpp
Outdated
Show resolved
Hide resolved
RecoLocalCalo/EcalRecAlgos/bin/makeEcalMultifitResultsGpuValidationPlots.cpp
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some remarks for future work, none of these are strictly required.
RecoLocalCalo/EcalRecProducers/plugins/EcalCPURecHitProducer.cc
Outdated
Show resolved
Hide resolved
RecoLocalCalo/EcalRecProducers/plugins/EcalCPURecHitProducer.cc
Outdated
Show resolved
Hide resolved
RecoLocalCalo/EcalRecProducers/plugins/EcalRecHitConvertGPU2CPUFormat.cc
Outdated
Show resolved
Hide resolved
RecoLocalCalo/EcalRecProducers/plugins/EcalRecHitConvertGPU2CPUFormat.cc
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two additional comments that need to be addressed before the GPU producer can be used with a SwitchProducer on a non-GPU machine.
RecoLocalCalo/EcalRecProducers/plugins/EcalRecHitProducerGPU.cc
Outdated
Show resolved
Hide resolved
RecoLocalCalo/EcalRecProducers/plugins/EcalRecHitProducerGPU.cc
Outdated
Show resolved
Hide resolved
This comment has been minimized.
This comment has been minimized.
Validation summaryReference release CMSSW_11_1_0_pre8 at 442ae07 Validation plots/RelValTTbar_14TeV/CMSSW_11_0_0_patch1-PU_110X_mcRun3_2021_realistic_v6-v1/GEN-SIM-DIGI-RAW
/RelValZMM_14/CMSSW_11_0_0_patch1-110X_mcRun3_2021_realistic_v6-v1/GEN-SIM-DIGI-RAW
/RelValZEE_14/CMSSW_11_0_0_patch1-110X_mcRun3_2021_realistic_v6-v1/GEN-SIM-DIGI-RAW
Throughput plots/EphemeralHLTPhysics1/Run2018D-v1/RAW run=323775 lumi=53logs and
|
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
Include standalone executables for the validation of ECAL uncalibrated and calibrated rechits.
From uncalibrated rechit to rechit on GPU, in CMSSW_11_1_X
The PR includes validation code for rechit comparison, similar to what shown at ECAL DPG meeting.
Some to the files changed are just "c++ stylistic", it can be reversed (I needed to debug).
Similar to #457 but mergeable.