-
Notifications
You must be signed in to change notification settings - Fork 37
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
Added SimDRCalorimeterHit for dual-readout #380
base: main
Are you sure you want to change the base?
Conversation
Hi, |
edm4hep.yaml
Outdated
- int32_t eta // detector cell eta | ||
- int32_t phi // detector cell phi | ||
- int32_t depth // detector cell depth | ||
- int32_t system // detector cell system |
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.
Why do you need these when there is already cellID?
edm4hep.yaml
Outdated
- std::array<int32_t, 6000> nwavelen_cer // number of cerenkov wavelength hits | ||
- std::array<int32_t, 6000> nwavelen_scint // number of scint wavelength hits | ||
- std::array<int32_t, 6000> ntime_cer // number of cerenkov time hits | ||
- std::array<int32_t, 6000> ntime_scint // number of scint hits |
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.
What is stored in these arrays? What is the index? Why 6000?
This feels awfully inefficient.
Hi Wonyong, thanks. Do I understand correctly that, for DRCrystals, SimCalorimeter hits are not an option? Is it because, unlike for DRFibers (see key4hep/k4geo#411), both C and S photons are produced by the same sensitive volume? Is the need for storing wavelength coming from the fact that you need it for wavelength dependent effects in the digitization? |
Hi Brieuc, |
Hi, I've updated the class wrt the comments above. Please take a look. |
I was wondering whether we could just use two collections (one for the scintillation, one for the cherenkov channel) instead of implementing the dedicated data format (though I also opt to include the time information to the |
If that would be possible then I think that would be the easiest solution. Do you already have some digitization code, where it could be exercises how workable that solution actually is there?
We already discussed adding a The main open question at that point was, what should be stored in the |
- uint64_t cellID // detector cellID | ||
- float energy [GeV] // energy of the hit | ||
- edm4hep::Vector3f position [mm] // position of the calorimeter cell in world coords | ||
- int32_t nCerenkovProd // number of cerenkov photons produced |
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.
Why produced photons? Why not recorded photons? Similar to having the avg arrival time of photons recorded in the time fields?
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.
This is a SIM level object, I guess we should leave the possibility to treat effects such as efficiency in a subsequent digitizer (though it is indeed sometimes interesting to leak part of the digitization in the SDAction)
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.
But then the tAvg should also come from the digitiser and not be calculated here already?
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 input from side. Our idea here is to have a first functional simulation which is a sufficiently good representation of the detector performance. The definition of the technology is still being matter of R&D and thus we are not ready yet to work on the digitization part. At this first stage, in our opinion, the most efficient approach (also from the computational time point of view) is to factorize the simulation of energy deposition part from that of optical photon tracing, SiPM and electronics.
From the former we need:
- number of cherenkov photons produced (we can then apply offline, at the reconstruction level a scaling on this number which takes into account the light collection efficiency, i.e. light tracing aspects)
- amount of energy deposited in each calorimetric cell
For what concerns the time stamp it is often sufficient to save the average time of all hits inside a certain calorimetric cell (possibly weighed with the energy of each hit). This is for our calorimeter a sufficiently good approximation of the time information we can extract with a realistic system (possibly after applying a resolution smearing).
It is to early to have a realistic implementation of the digitizer step in my opinion because of two reasons:
- we want to explore different configurations and for this it is more convenient to apply "digitization" effects offline
- simulation of optical photons is very time consuming so we are looking into a way to parametrize all optical aspects as much as possible (based on standalone Geant4 studies)
Concerning having separate collections for the scintillation and cherenkov photons this is also possible I believe. However, the difference with respect to the dual-readout fiber calorimeter is that in our case we have a complete duplications of hits since the cherenkov photons are always produced in the same volumes as that of other hits. Having two separate collections looked like redundant (I don't know about the impact on data size). For each hit in a certain calorimetric cell we always have both scintillation and cherenkov non-zero signals. If we use two separate collections we will have to match one-by-one all hits at the reconstruction level.
BEGINRELEASENOTES
ENDRELEASENOTES