Add SimCalorimeterPulse data type for storing simulated calorimeter pulses pre-digitization
#106
Conversation
…dd relation to SimCalorimeterPulse
| - float amplitude // Pulse amplitude in [GeV], sum of amplitude values equals total energy | ||
| OneToManyRelations: | ||
| - edm4hep::SimCalorimeterHit hits // SimCalorimeterHits used to create this pulse | ||
| - edm4hep::SimCalorimeterPulse pulses // SimCalorimeterPulses used to create this pulse |
There was a problem hiding this comment.
| - edm4hep::SimCalorimeterPulse pulses // SimCalorimeterPulses used to create this pulse | |
| - edm4eic::SimCalorimeterPulse pulses // SimCalorimeterPulses used to create this pulse |
| Members: | ||
| - uint64_t cellID // ID of the readout cell for this pulse. | ||
| - float energy // Total energy for this pulse in [GeV]. | ||
| - float position // Position of the hit in world coordinates [mm]. |
There was a problem hiding this comment.
(comment from @simonge and @ruse-traveler )
Should be a Vector3f.
| @@ -244,6 +244,22 @@ datatypes: | |||
| ## ========================================================================== | |||
| ## Calorimetry | |||
| ## ========================================================================== | |||
| edm4eic::SimCalorimeterPulse: | |||
There was a problem hiding this comment.
We would really want to have generic structures to be able to consistently handle basic operations (adding noise, merging pulses, etc) for different detectors, not just calorimeters.
Would it be acceptable to make a more generic-sounding name, even if we keep the edm4hep::SimCalorimeterHit relation?
| OneToManyRelations: | ||
| - edm4hep::SimCalorimeterHit hits // SimCalorimeterHits used to create this pulse | ||
| - edm4hep::SimCalorimeterPulse pulses // SimCalorimeterPulses used to create this pulse | ||
| - edm4hep::MCParticle MCParticle // MCParticle that caused the pulse |
There was a problem hiding this comment.
| - edm4hep::MCParticle MCParticle // MCParticle that caused the pulse | |
| - edm4hep::MCParticle particle // MCParticle that caused the pulse |
There was a problem hiding this comment.
See also a similar change pushed through in edm4hep for technical reasons outlined there; key4hep/EDM4hep@cb738b0#diff-41291f568217a9755476ae21a12825127ae5a00179b19e867cffd64e3ceea36f
| - float time // Start time for the pulse in [ns]. | ||
| - float interval // Time interval between amplitude values [ns]. | ||
| VectorMembers: | ||
| - float amplitude // Pulse amplitude in [GeV], sum of amplitude values equals total energy |
There was a problem hiding this comment.
Comment from @veprbl during the meeting: should the units here be GeV? Or should these be in units of voltage?
If we choose to generalize the structure, then we should revisit this. Maybe it could be reformulated to be more generic; perhaps similar to the edm4hep::TimeSeries...
There was a problem hiding this comment.
But this is a truth type, not a digitized type. There is no concept of voltage until you have a digitization model. You could argue that energy is not the right quantity for a photon pulse traveling down a fiber either, but it probably should be closer to energy than to voltage.
There was a problem hiding this comment.
Measured energy deposition is not "truth", it's just another detail of detector technology. Also, there is not much practical use of truth-only type. You will want to process those pulses, and the type of amplitude scale will change along the way, the units won't stay as "GeV".
There was a problem hiding this comment.
It's truth in the sense that it is exactly what Geant4 gives. It is like energy of calo hit contributions. Yes, you can change the size of the volume those go in, but it is the exact energy contribution for the tracks in that volume, without distorting effects such as poisson distributions, gaussian measurement uncertainty, or bit depth quantization. It is so "true" that in many cases it is not even representative because it is just one sample out of many possibilities.
| - float energy // Total energy for this pulse in [GeV]. | ||
| - float position // Position of the hit in world coordinates [mm]. |
There was a problem hiding this comment.
Comment from @simonge during meeting: the energy and position can technically be obtained from the amplitude vector and cell ID respectively.
There was a problem hiding this comment.
We are going to run into the same discussions as for tracker hits here:
- someone will want both local and global positions
- someone will want extent since multiple cell IDs are combined
- someone will have a volume that is not aligned to any axes where extent makes any sense...
No suggestion.
Briefly, what does this PR introduce?
This PR adds a new data type,
edm4eic::SimCalorimeterPulse, to represent simulated calorimeter pulses before digitization.The new structure is modeled consistently with
edm4hep::SimCalorimeterHitand aligns with existing waveform structures such asedm4hep::RawTimeSeries(generic digitization output) andedm4hep::TimeSeries(generic measured time series).SimCalorimeterPulsedefines three one-to-many relations relations:SimCalorimeterHit: Pulses can be constructed from contributions of one or more simulated calorimeter hits.SimCalorimeterPulse: Pulses can be constructed out of other pulses.MCParticle: Each pulse can be attributed to a single MCParticle (primary pulse), multiple MCParticles (overlayed pulses), or zero MCParticles (noise pulse).Storing calorimeter pulses at the simulation level ensures conceptual clarity and consistency within our data model. The simulated pulse data to be stored in this structure have no equivalent in real detector output, and are therefore not digitization output.
By using a Simulation structure, we gain direct
Relationsupport with other simulation entities, enabling efficient backward navigation through the simulation chain. While Associations are used to link digitization and reconstruction structures to simulation, Relations are preferred for internal connections within the same domain (e.g. within Simulation or within Reconstruction). This design avoids introducing redundant Association types and keeps the data model consistent, clean and efficient.What kind of change does this PR introduce?
Please check if this PR fulfills the following:
Does this PR introduce breaking changes? What changes might users need to make to their code?
No
Does this PR change default behavior?
No