Iss1110 hcal lookuptables #55
Conversation
ehrlich-uva
commented
Nov 4, 2022
ehrlich-uva
commented
- Added a photon generator using lookup tables in Hcal. It generates individual photons based on the deposited energy of the track going through the scintillator.
- Added a SiPM charge generator that simulates the response of the SiPM pixels to incoming photons.
- The original code is still available and can be turned on by removing the #define NEWCODE preprocessor directive.
There was a problem hiding this comment.
@ehrlich-uva Starting a mini-review while trying to integrate this code.
src/Hcal/HcalDigiProducer.cxx
Outdated
|
|
||
| //TODO: temporary implementation for getting the scintillator length | ||
| int length=(int)(2.0*hcalGeometry.getHalfTotalWidth(section,(layer%2==1?layer+1:layer-1)) + 0.5); //rounded to closest int to avoid mismatches due to precission of floating point numbers | ||
| int reflectorType=(section==ldmx::HcalID::HcalSection::BACK?0:2); |
There was a problem hiding this comment.
@ehrlich-uva - I'm starting a little review of this code. Can you clarify what does reflector Type mean? What is the meaning of 0,1 and 2?
There was a problem hiding this comment.
reflector types:
0: the counter has SiPMs on both ends, i.e. no reflector or absorber on either side.
1: the counter has a SiPM on one side, and a reflector on the other side.
2: the counter has a SiPM on one side, and an absorber on the other side.
There was a problem hiding this comment.
I see, do counters in the SideHcal have always an absorber in the other side? how do you distinguish a reflector from an absorber in the scintillatorbar object? @EinarElen this is not something implemented in our current G4 simulation right?
There was a problem hiding this comment.
As far as I understand, all SideHcal counters have absorbers on the other side. If not, I need to change the code.
It would be nice, if the presence/location of absorbers/reflectors of a counter or module came from the hcalGeometry, so that I don't have to hard code it in HcalDigiProducer.cxx (line 177). Same is true for the counter length (line 176).
The reflector or absorber is only relevant for the photons inside the embedded fiber. So it wouldn't be part of the G4 simulation, because we don't simulate individual photons at this stage. That's why this PR implements lookup tables that were generated in a standalone G4 program (outside the LDMX code) that simulates photons.
src/Hcal/HcalDigiProducer.cxx
Outdated
| int trackID = simHit.getContrib(0).trackID; //There should only be 1 contributions for Hcal hits | ||
| double charge = particleMap[trackID].getCharge(); | ||
|
|
||
| int absorber=0; //no absorber at back section |
There was a problem hiding this comment.
What does "no absorber" at the back section mean?
There was a problem hiding this comment.
The counters at the back section of the Hcal have SiPMs on both ends, i.e. no absorbers. I use this as an initial value. The next couple of lines deal with all other Hcal sections and set the value of the absorber variable to 2 or -2, if necessary (the negative sign indicates that the absorber is at the negative end of the counter).
src/Hcal/HcalDigiProducer.cxx
Outdated
| } | ||
| scintillationYieldsAdjusted_.clear(); | ||
|
|
||
| // Configure charge generator |
There was a problem hiding this comment.
@ehrlich-uva do you have a reference for the parameters you chose below? What does pixel mean in the context of the charge generator? do all SiPMs have 40x40?
There was a problem hiding this comment.
I got them from the specs of the Mu2e CRV SiPMs (Hamamatsu S13360-2050VE). I used these value, because I didn't know the values of the HCal SiPMs. I think it's Ok for now, but should eventually be changed.
There was a problem hiding this comment.
The SiPM consist of a number of pixels, and each pixel is treated separately (except for cross-talk, where pixels can cause an avalanche at neighboring pixels). The detection probability, dark counts, charging/discharging behavior, avalanche probability and pulse strength are simulated for each pixel individually. Saturation effects are simulated indirectly, too.
|
This pull request is very old and I haven't looked at it in a long time. If I remember correctly, the pull request was put on hold, because some functions in some LDMX geometry classes needed to be added or updated. |
src/Hcal/HcalDigiProducer.cxx
Outdated
|
|
||
|
|
||
| const std::vector<double> ×PosEnd=photonGenerator->second->GetArrivalTimes(1); //SiPM1 is at the positive and in the photonGenerator | ||
| const std::vector<double> ×NegEnd=photonGenerator->second->GetArrivalTimes(0); //SiPM0 is at the negative end in the photonGenerator |
There was a problem hiding this comment.
@ehrlich-uva What shall we interpret as the positive and negative end in the photonGenerator? Does the photonGenerator know about the global geometry and whether positive end means +X/+Y?
There was a problem hiding this comment.
In this code, I define the positive sides to be at +x/+y/+z and set SiPM 1 at the positive side of a counter. Based on this, I decide at lines 215 ... 231 at which side the absorber is located at the counter (-2 at the negative side and +2 at the positive side). The photon generator uses this information to decide whether SiPM 0 or SiPM 1 gets read out.
|
@ehrlich-uva Indeed the PR is old but I want to restructure it and see what are we missing. Einar worked on some of the HcalGeometry functions earlier and we may just be missing a couple of useful functions to implement this PR. |
|
With the impending submodule->subdirectory transition on Wednesday, I am commenting here to remind you to either merge this PR before then or close it and re-apply the changes after Wednesday to make a new PR on the subdirectory of ldmx-sw. |
|
I have already done the transition and am in the final stages of testing. Updating submodule changes to apply to subdirectories is not a difficult process and one that I've tested on my own branch of the ECal submodule. Please follow those instructions and re-open this PR in ldmx-sw off the new trunk. |
