Hcal tot digitization
I am updating ldmx-sw, with implemented Hcal TOT digitization.
What are the issues that this addresses?
Check List
- [ ] I successfully compiled ldmx-sw with my developments
- [ ] I ran my developments and the following shows that they are successful.
New Class 'PulseRecord':
This class is intended solely for plotting purposes and should not interfere with the existing workflow. The PulseRecord(double volts, int adc, int tot) function temporarily stores the digitized pulses when the HgcrocEmulator is called by either the Hcal or Ecal pipelines and is cleared each time the emulator is invoked. If the pulse is digitized using ADC, the TOT value is set to zero, and vice versa.
To my understanding, the HgcrocEmulator cannot be called by the Ecal and Hcal pipelines at the exact same time. Therefore, when the getter for PulseRecord is called within the HcalDigiProducer, it will only retrieve the digitized information corresponding to the pulses sent for digitization at that moment. If this understanding is incorrect, the class may only be suitable for studying the back Hcal.
HgcrocEmulator
HgcrocEmulator.h has been amended with a mutable vector ‘pulseRecord_’ and a getter to access ‘pulseRecord_’ to store and access digitizations.
Originally, the TOT digitization for an incoming pulse was set by comparing the voltage (vpeak) of the hit, calculated using the pulse function at the time of the hit that comes with the pulse. However, in ADC digitization, the voltage (bxvolts) is calculated using iADC and the clock cycle. There is a slight difference between the two voltage values. See the following debug print.
If we used the original setting:
if (vpeak > totThreshold) { startTOT = true; }
ADC and TOT digitizations look like this. Note that the ADC digitization does not reach up to 1024 counts here.
Instead, if we modify the code as follows, the complete ADC range is utilized in the digitization:
if (bxvolts > totThreshold){
/startTOT = true;
}
In this branch, the ‘bxvolts > totThreshold’ condition is currently used.
HcalDigiProducer
Once each section in HcalDigiProducer sends pulses to HgcrocEmulator, they are accessed through the getter and temporarily stored in the vector ‘DigiToPlot’, which is cleared for each ‘hitsByID’ in the loop. At the end of each section, the recorded digitized info is written into a text file following the format [Voltage ADC TOT]. The plots I showed above were generated using that text file.
hcal_hardcoded_conditions.py and proposed TOT reconstruction
Please see the following presentation to understand how changes were made to hcal_hardcoded_conditions and how TOT reconstruction can be implemented.
Discussion
Before the implementation of TOT digitization, the histogram of Hcal reconstructed energy was piling up towards the last bins. However, after the implementation, we now observe a smoothed decay in the reconstructed energy. Please note that the appropriate parameters for reconstruction have not yet been configured.
@vrm7fj @cmantill what's the status of this? (There are new conflicts)
@cmantill should we close this PR for the time being, until you have somebody to take over? Or maybe @erik-wallin could help in with this development?
#1740 mostly achieves the same goals as this PR, apart from updating the default HGCROC emulator conditions. I'm currently producing MC samples for the testbeam analysis and working on tuning the conditions to match the real data, and they don't quite match the values here. I think it makes sense to use numbers that reflect what we saw at the TB, rather than to pick numbers from the data sheet.
The larger project here is actually using TOT in the reconstruction. In the TB MC samples the transition between the ADC region and TOT region looks quite good:
So I think it will be quite easy to update HCalRecHitProducer to make use of TOT. I probably won't do that in this particular PR though
I think that most the work to use TOT in the reconstruction was done in the changes to the hcal reco conditions in this PR. So we can close this PR but we should open an issue to address this. I hope Erik can do this (I can help guide!) given that #1740 was merged already.
So we can close this PR but we should open an issue to address this.
@cmantill @erik-wallin could one of you make that issue?
OK I made the issue: https://github.com/LDMX-Software/ldmx-sw/issues/1787
Please feel free to edit it!