-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Add HcalHPD type #17326
Add HcalHPD type #17326
Conversation
A new Pull Request was created by @kpedro88 (Kevin Pedro) for CMSSW_9_0_X. It involves the following packages: CalibCalorimetry/HcalAlgos @ghellwig, @arunhep, @cerminar, @cmsbuild, @franzoni, @mmusich, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
@cmsbuild please test |
The tests are being triggered in jenkins. |
Comparison job queued. |
Giovanni and Arun, this is a technical amendment/extension to correctly describe what has already been submitted to Plan 0 conditions, namely https://hypernews.cern.ch/HyperNews/CMS/get/calibrations/2808.html Please, approve. |
@franzoni, @arunhep ping |
else theType = HcalHPD; | ||
} else if (fId.genericSubdet() == HcalGenericDetId::HcalGenOuter) { | ||
if(useHOUpgrade_) theType = HcalHOHamamatsu; | ||
else theType = HcalHPD; | ||
} |
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.
Hi @kpedro88
sorry for coming to this only now.
I try to understand the change of the logic here:
It looks to me as if the new enum type is used in case of useHOUpgrade == false
or useHEUpgrade == false
, i.e. it is only valid for past runs?
Where is this type then used and what purpose does it serve?
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.
We still have HPDs installed in the HB and HE. The hardcode conditions are intended to be used for development/testing for any HCAL scenario, not just future ones.
This type will be used to store HPD photoelectronToAnalog value in the database, as discussed in #17311 and https://hypernews.cern.ch/HyperNews/CMS/get/calibrations/2808.html.
@@ -35,7 +35,7 @@ | |||
qieSlope = cms.vdouble(0.912,0.917,0.922,0.923), | |||
mcShape = cms.int32(125), | |||
recoShape = cms.int32(105), | |||
photoelectronsToAnalog = cms.double(0.0), | |||
photoelectronsToAnalog = cms.double(0.3305), | |||
darkCurrent = cms.vdouble(0.0), |
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.
The rest of the code changes looks like really just related to the additional enum, but what is the rationale behind this configuration parameter change?
Why does this value needs to be changed?
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.
Previously this value was only stored in Python (https://github.com/cms-sw/cmssw/blob/CMSSW_9_0_X/SimCalorimetry/HcalSimProducers/python/hcalSimParameters_cfi.py). Now it will be used in Method 2 reconstruction as well as digi simulation, so it will be taken from the database as noted in my above comment and the PR description. Once this PR and the conditions updates are accepted, the Python config can be cleaned up to reduce duplication.
@@ -48,7 +48,7 @@ | |||
qieSlope = cms.vdouble(0.912,0.916,0.920,0.922), | |||
mcShape = cms.int32(125), | |||
recoShape = cms.int32(105), | |||
photoelectronsToAnalog = cms.double(0.0), | |||
photoelectronsToAnalog = cms.double(0.3305), | |||
darkCurrent = cms.vdouble(0.0), |
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.
see above
@kpedro88 thanks for the clarifications! |
Originally, all the values in HcalDbHardcode were actually hardcoded in C++. I've modernized it to be configurable in Python for many values (not all) over the past few years. The old name was retained because no one cared enough to change it. |
+1 |
This pull request is fully signed and it will be integrated in one of the next CMSSW_9_0_X IBs (tests are also fine). This pull request requires discussion in the ORP meeting before it's merged. @davidlange6, @smuzaffar |
@davidlange6 |
it was approved 28 minutes ago… yes, I’m aware of it
… On Feb 10, 2017, at 5:28 PM, Slava Krutelyov ***@***.***> wrote:
@davidlange6
this is one of the PRs needed for the HCAL M2 update and will need a sequence of events to happen from this PR to GT update to take effect on physics result.
Please merge or comment at your earliest.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
+1 |
Based on discussions in #17311, this PR adds an "HcalHPD" type to the
HcalSiPMType
enum. This is done in order to access per-channelphotoelectronsToAnalog
values for HPDs from the database, repurposing theSiPMParameters
object. The hardcode conditions are updated appropriately. All other values for SiPM-related quantities will be set to dummy values, since they will not be used for HPDs.I tested the effect of this PR locally by changing the
photoelectronsToAnalog
value inHcal_Conditions_forGlobalTag_cff
and observing changes in digi, rechit, etc. distributions. No changes in central workflows are expected.Updates to the database conditions for HCAL will follow separately. Removal of the
photoelectronsToAnalog
Python parameter inhcalSimParameters_cfi
may also follow separately.attn: @abdoulline, @mariadalfonso