HBHE M2: add missing photoStatistics uncertainties #17311
Conversation
|
A new Pull Request was created by @mariadalfonso for CMSSW_9_0_X. It involves the following packages: RecoLocalCalo/HcalRecAlgos @cmsbuild, @cvuosalo, @slava77, @davidlange6 can you please review it and eventually sign? Thanks. cms-bot commands are listed here #13028 |
| if(!channelData.hasTimeInfo() && (charge-ped)>channelData.tsPedestalWidth(ip)) { | ||
| // the fcByPE is not in the DB, but is hard coded in python | ||
| // https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_0/SimCalorimetry/HcalSimProducers/python/hcalSimParameters_cfi.py#L62 | ||
| // Note in DIGI (from kPedro): the output number of photoelectrons after smearing is treated very differently for SiPMs: *each* pe is assigned a different time based on a random generation from the Y11 pulse plus the SimHit time. In HPDs, the overall pulse is shaped all at once using just the SimHit time. |
There was a problem hiding this comment.
please add some linebreaks in the comment
There was a problem hiding this comment.
@slava77 sure done
| // the fcByPE is not in the DB, but is hard coded in python | ||
| // https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_0/SimCalorimetry/HcalSimProducers/python/hcalSimParameters_cfi.py#L62 | ||
| // Note in DIGI (from kPedro): the output number of photoelectrons after smearing is treated very differently for SiPMs: *each* pe is assigned a different time based on a random generation from the Y11 pulse plus the SimHit time. In HPDs, the overall pulse is shaped all at once using just the SimHit time. | ||
| noisePHArr[ip] = (charge-ped)/sqrt(0.3305*16); |
There was a problem hiding this comment.
by the time we can comment it out, please define a common constant in python and use it both in hcalSimParameters_cfi and in m2 configuration.
in photoelectronsToAnalog = cms.vdouble([0.3305]*16) is a 16-times repeat of 0.3305. do these all add up to lead to "0.3305*16"?
|
|
||
| // Note2. (from kPedro): the output number of photoelectrons after smearing is treated very differently for SiPMs: *each* pe is assigned a different time based on a random generation from the Y11 pulse plus the SimHit time. In HPDs, the overall pulse is shaped all at once using just the SimHit time. | ||
|
|
||
| noisePHArr[ip] = (charge-ped)/sqrt(0.3305*16); |
There was a problem hiding this comment.
[reposted, since the earlier one became hidden]
by the time we can comment it out, please define a common constant in python and use it both in hcalSimParameters_cfi and in m2 configuration.
in photoelectronsToAnalog = cms.vdouble([0.3305]*16) is a 16-times repeat of 0.3305. do these all add up to lead to "0.3305*16"?
There was a problem hiding this comment.
@slava77 it is a per-tower (ieta) value in the hcalSimParameters config.
There was a problem hiding this comment.
@igv4321, @kpedro88 (including Igor and Kevin in the thread)
Just would like to mention that this is supposed to be ieta-dependent HB constant/factor. That's why there is an array of 16 in the photoelectronsToAnalog = cms.vdouble([0.3305]*16)
So the actual constant is just 0.3305 (sic), as described in the HB QIE8 digitization description:
https://indico.cern.ch/event/603091/contributions/2441161/attachments/1397849/2131705/HPD_QIE8_digitization.pdf
Currently this HB constant(s) is in SIM config, which must not be accessed by RECO, so as Slava mentioned, it should be somewhere on a "neutral ground" (e.g. Calibcalorimetry/HcalPlugins)
So. I'd suggest to make a small config in
http://cmslxr.fnal.gov/source/CalibCalorimetry/HcalPlugins/python/
accessible both by
(1) http://cmslxr.fnal.gov/source/SimCalorimetry/HcalSimProducers/python/hcalSimParameters_cfi.py
(2) http://cmslxr.fnal.gov/source/RecoLocalCalo/HcalRecProducers/python/HBHEMethod2Parameters_cfi.py
There was a problem hiding this comment.
@slava77 I replaced the slides in the PR description with results from noisePHArr[ip] = (charge-ped)/sqrt(0.3305); things get even better, I will update the code (but keep commented) when the bot finish his tests)
|
@cmsbuild please test |
|
The tests are being triggered in jenkins. |
|
Comparison job queued. |
|
... our posts crossed (I'm a bit slow, being at the HCAL meeting)...
…On Sun, 29 Jan 2017, Kevin Pedro wrote:
@kpedro88 commented on this pull request.
______________________________________________________________________________
In RecoLocalCalo/HcalRecAlgos/src/PulseShapeFitOOTPileupCorrection.cc:
> + // sigmaFC/FC = 1/sqrt(Ne);
+ noisePHArr[ip] = 0;
+ if(channelData.hasTimeInfo() && (charge-ped)>channelData.tsPedestalWidth(
ip)) {
+ noisePHArr[ip] = (charge-ped)/sqrt((charge-ped)/channelData.fcByPE());
+ }
+
+ /*
+ // FIXME: in the future switch the photostatistics on also for the HPD
+ if(!channelData.hasTimeInfo() && (charge-ped)>channelData.tsPedestalWidth
(ip)) {
+
+ // Note1. the fcByPE is not in the DB, but is hard coded in python
+ // https://github.com/cms-sw/cmssw/blob/CMSSW_8_1_0/SimCalorimetry/Hcal
SimProducers/python/hcalSimParameters_cfi.py#L62
+
+ // Note2. (from kPedro): the output number of photoelectrons after smea
ring is treated very differently for SiPMs: *each* pe is assigned a different
time based on a random generation from the Y11 pulse plus the SimHit time. In
HPDs, the overall pulse is shaped all at once using just the SimHit time.
+
+ noisePHArr[ip] = (charge-ped)/sqrt(0.3305*16);
@slava77 it is a per-tower (ieta) value in the hcalSimParameters config.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the
thread.[AEx02qMvoA_T-rAtPOxMsvodviGKRyx5ks5rXJq9gaJpZM4Lwvhb.gif]
|
|
@abdoulline as an alternative to rearranging configs, if we are going to be relying on the pe2fc value for reconstruction (rather than just simulation), we may want to specify it per-channel in the database. Supposedly the pe2fc value was initially measured for each HPD by someone at Minnesota (not sure if we can expect the values to be constant over time). We could repurpose the SiPMParameters database object for this - just define an "SiPM type" value corresponding to HPDs. (A bit kludgey, but we've done worse.) |
|
@kpedro88 - right, I also thought about using SiPMParameters earlier today, but it looked not quite logical (indeed) at the beginning... But once you also suggest it, I start thinking ("Il n'y a que les imbéciles qui ne changent pas d'avis"(c)) that it well may be the simplest way of "unification" of fCbyPE usage (in HPD case) for M2. Actually we have right away for non-SiPMs: 0 HcalNoSiPM as SiPMS type. |
|
@kpedro88 |
|
@abdoulline my thought was to define a new "HcalHPD" type (separate from HcalNoSiPM = 0), then |
|
@abdoulline @kpedro88 |
|
@mariadalfonso I tend to agree; if it won't be used for 2017 startup, we have more time to consider. I don't think anyone knows if HPD pe2fC is dependent on time, but there may be some channel dependence. @hatakeyamak @deguio this could be a topic for the DPG to investigate if the initial HPD measurements can be found. |
|
@mariadalfonso In principle, this HPD property can vary (to some small extent) from HPD to HPD. |
|
Given that
Can you put me in the condition to test the HPD simulation with the same siPM approach ? |
|
The SiPM approach is needed in order to handle the nonlinearity correctly - the time of each photon hitting the SiPM must be known. It is otherwise statistically equivalent to the HPD approach: random generation (Y11) + smearing (photodetector pulse) vs. smearing (convolution of Y11 + photodetector pulses). Maybe the ingredients in the HPD pulse shape calculation https://github.com/cms-sw/cmssw/blob/CMSSW_9_0_X/CalibCalorimetry/HcalAlgos/src/HcalPulseShapes.cc#L138 should be revised, but I have no special knowledge on that topic. |
|
Maria, we saw that (accidentally) increased noise/errors (p.e.) brought
quite good results for HPD timing (not just obvious Chi2 lowering), namely - no more two timing "bands". For me this is yet another *indication* that current RECO MC shape (105) needs to be adapted accordingly for MC (->106, as Kenichi calls it), as we've discussed earlier/elsewhere. And possibly other noise sources to be evaluated (in addition to quantization/delayed hits/photostatistics).
We can discuss in person, if you want, why assigning individual time to p.e. for HPD according to already all-components-convoluted pulse 125 is not worth it (compared to the current approach).
…On Tue, 31 Jan 2017, mariadalfonso wrote:
@kpedro88 @abdoulline
Given that
1.
the HPD data behave much better than the HPD MC (chi2/timing)
http://dalfonso.web.cern.ch/dalfonso/dalfonso_PhotoStatisticsFIX.pdf
2.
"the output number of photoelectrons after smearing is treated very differently for SiPMs: each pe is assigned a
different time based on a random generation from the Y11 pulse plus the SimHit time. In HPDs, the overall pulse is
shaped all at once using just the SimHit time"
Can you put me in the condition to test the HPD simulation with the same siPM approach ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.[AEx02sLBUmGPWYeA7z1q_0Iuj9G_UEbeks5rXyGRgaJpZM4Lwvhb.gif]
|
|
Kevin, I'm late again :-)
|
|
@abdoulline I'm left to keep doing "reverse engineering" of what come to me as input hopefully we learn more stuff and take better data that in 2015. |
|
BTW, some time ago, when several ways were considered of improving the HPD DIGI/RECO (MC) situation, one option (second to 105->106 move) was listed as modification of DIGI pulse 125 to deliver DIGIs better suited for existing RECO pulse 105. But it's considered as medium-term task. Hopefully we'll discuss these matters tomorrow morning at the meeting called by Federico. |
|
Hm... As far as understand the physics and the statistics, adding
noise and then smearing is statistically dissimilar from smearing
first and then adding noise. To illustrate this, consider the following
very simple idealized scenario: the Y11 pulse is very short, while HPD+QIE8
combo functions as a linear (really linear) filter. Then each photoelectron
registered causes the same response, and fluctuations in the number
of photoelectrons cause fluctuations only in the response magnitude
but not in its shape.
Of course, presence of nonlinearities in the response makes things more
complicated, but nevertheless the HPD+QIE8 combo functions, to first
order, as a variable-bandwidth filter. It does matter to the time structure
whether the wide-bandwidth noise (Poisson fluctuations) is added before
the filter or after the filter.
…On 01/31/2017 06:12 AM, Salavat Abdullin wrote:
Kevin, I'm late again :-)
<...>
It is otherwise statistically equivalent to the HPD approach: random generation (Y11) + smearing
(photodetector pulse) vs. smearing (convolution of Y11 + photodetector pulses)
<...>
* That's what I meant in my last sentence.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#17311 (comment)>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFS4-aBuit64pFqyFtVDaZ5wEDa6SAHQks5rXyVJgaJpZM4Lwvhb>.
|
|
The Poisson smearing for photostatistics occurs before the pulse shape smearing/random generation for both HPDs and SiPMs. |
|
Igor, in principle you're right, in case of extreme spread there woud be
some difference, but in most of the cases we have 1-2 SimHits with 1-2ns
spread. That's what why I believe it's not worth it.
…On Tue, 31 Jan 2017, Igor Volobouev wrote:
Hm... As far as understand the physics and the statistics, adding
noise and then smearing is statistically dissimilar from smearing
first and then adding noise. To illustrate this, consider the following
very simple idealized scenario: the Y11 pulse is very short, while HPD+QIE8
combo functions as a linear (really linear) filter. Then each photoelectron
registered causes the same response, and fluctuations in the number
of photoelectrons cause fluctuations only in the response magnitude
but not in its shape.
Of course, presence of nonlinearities in the response makes things more
complicated, but nevertheless the HPD+QIE8 combo functions, to first
order, as a variable-bandwidth filter. It does matter to the time structure
whether the wide-bandwidth noise (Poisson fluctuations) is added before
the filter or after the filter.
On 01/31/2017 06:12 AM, Salavat Abdullin wrote:
>
> Kevin, I'm late again :-)
> <...>
> It is otherwise statistically equivalent to the HPD approach: random generation (Y11)
+ smearing
> (photodetector pulse) vs. smearing (convolution of Y11 + photodetector pulses)
> <...>
>
> * That's what I meant in my last sentence.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
<#17311 (comment)>, or mute the thread
><https://github.com/notifications/unsubscribe-auth/AFS4-aBuit64pFqyFtVDaZ5wEDa6SAHQks5
rXyVJgaJpZM4Lwvhb>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.[AEx02jdHKqhfcBYY4Pe1jBbuN3edntXYks5rX11igaJpZM4Lwvhb.gif]
|
|
Well, I guess I am still missing the big picture... What is then
the time structure of the fluctuations we are simulating for HPDs?
Y11 response is precisely where most of that time structure is created
in reality.
…On 01/31/2017 10:14 AM, Kevin Pedro wrote:
The Poisson smearing for photostatistics occurs before the pulse shape smearing/random generation for both HPDs and SiPMs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#17311 (comment)>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFS4-dne0vzWL-WLZkAoGdJkp646Uwplks5rX13dgaJpZM4Lwvhb>.
|
|
Imagine you have one SimHit for simplicity: |
|
OK, thanks, so now it is obvious where this sequence diverges
from data. What happens in reality is that the time structure
of the noise is generated, chiefly, according to the Y11 component
of shape 125 and not the whole shape 125. Then the smearing
happens according to HPD+QIE8 response.
Where is the place of pile-up addition in this sequence?
…________________________________
From: Salavat Abdullin [notifications@github.com]
Sent: Tuesday, January 31, 2017 10:51 AM
To: cms-sw/cmssw
Cc: Volobouev, I; Mention
Subject: Re: [cms-sw/cmssw] HBHE M2: add missing photoStatistics uncertainties (#17311)
Imagine you have one SimHit for simplicity:
E_simhit -> fC -> Np.e. -> Poisson Np.e. -> fC -> distribute over CaloSamples using shape 125 (convolution of all timing components) -> TimeSlewSim -> add electronics noise...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#17311 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AFS4-cejfHQZsXA48oy5mTlKoglAh4Szks5rX2aogaJpZM4Lwvhb>.
|
|
Classic pileup mixing just adds more SimHits to the event, which are processed by the digi simulation in the exact same way as signal hits. Premixing instead creates a simulated RAW dataset with some distribution of interactions per event, and then converts those pileup digis back into CaloSamples to add to the CaloSamples generated in the digi simulation of the signal event. |
|
Before its beginning ("accumulation" of SimHits for given readout) in the regular mixing |
|
OK, thanks. In the "classic pileup mixing", what determines the SimHit timing? Is the time slice chosen at random? How does one distinguish the MC samples generated by "classic pileup mixing" and by "premixing"? |
|
The SimHits come from minbias gen-sim. I think their times get shifted to correspond to the bunch crossing for which they're used, but I'm not 100% sure of the details. Premixing has only recently been used for central MC production. Usually some part of the campaign will have "premix" in the name. |
|
Indeed, each added PU event (from <N_PU> simulated in each -N1 +N2 BXs = -12 As to the premixing... Just would like to mention that DIGI code is filled |
|
Admittedly we've filled this PR thread with quite extended discussions, but now it's probably too late to move to e-mail.,, Igor, once you continue thinking how to improve signal simulation, I'd like to add a couple of comments: (2) As I've already mentioned previously/elsewhere, in the current situation As we've discussed on several occasions, in MC we may try (i) to maximally mimic hardware (apparently neither Chris Tully nor Jeremy Mans nor Rick Wilkinson, who developed/maintained DIGI part over ~15 years, achieved that) or (ii) to make MC DIGI-RECO kind of self-consistent to put data vs MC "on par" at the very end. |
|
Just to comment: the reason there are all of those "Branches" in the code for PreMixing is that the hits have to be processed into fC with no additional smearing, noise, slew correction, ion-feedback, etc., etc. All that is required is the energy->charge conversion. It was difficult to do this without some ugly mangling of the code. Sorry! |
|
Mike, I didn't mean to complain/criticize (what I don't know well,
after all), but rather emphasize the machinery is rather complicated for
folding the things into PU premixed RAW and then to unfold it to "marry" the signal...
…On Wed, 1 Feb 2017, mdhildreth wrote:
Just to comment: the reason there are all of those "Branches" in the code for PreMixing is that the hits have to be
processed into fC with no additional smearing, noise, slew correction, ion-feedback, etc., etc. All that is required is
the energy->charge conversion. It was difficult to do this without some ugly mangling of the code. Sorry!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the
thread.[AEx02kbW1KcPCJe64WkvRTsRp6nyHuZhks5rYIiDgaJpZM4Lwvhb.gif]
|
|
plots are from CMSSW_9_0_X_2017-01-27-1100, before the plan-0 pi 5-5000 gun Time in the endcap is quite nicely around 0 without bumps (this is all hits) chi2 tail is gone the spike at chi2~1 looks quite suspicious in PU35 the same E<0.1 the change in PU35 The reduction is clearly expected given the increase in the chi2 denominator. Back to pi 5-5000 gun: In PU35 pretty large chunk of neutral hadrons is gone as a downstream effect Looking at response to gen-level "jets" from pi5-5000 show some 7% decrease in response in endcap for pt>~300 GeV the resolution apparently doesn't suffer. So, this could be calibrated away |
|
+1
On the technical side: in PU35 ttbar hbheprereco time is down from 3.4 to 1.9 s/event, indicating a faster convergence. |
cmsbuild
added
fully-signed
reconstruction-approved
and removed
pending-signatures
reconstruction-pending
labels
|
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 |
Added missing photoStatistics uncertainties in the M2 chi2.
clear benefits in both HPD and siPM
http://dalfonso.web.cern.ch/dalfonso/dalfonso_PhotoStatisticsFIX.pdf
This PR will be transparent for the plan0, as the kept the HPD fix commented for now.
a good plus if can be merged in the pre3 as facilitate the next developments.