RFC: Detector IDs, naming, channel IDs and node IDs

[olantwin]

Some points from our discussion at the simulation meeting today:

• Detector IDs should be class enumerations and follow official project names. We can exhaustively list the projects.
• Currently SimHits have channel IDs, this does not make sense. They should be geometry Node IDs.
• Channel IDs should be used for digitised hits, unique per Detector ID
• Internally, detectors/projects may use subdetector identifies (e.g. SD), but these should not require modifications on the global level

Comments and corrections appreciated!

@ShipSoft/core-developers @mesmith75 @matclim @ShipSoft/detector-responsibles

[eduard322]

I forgot to ask or maybe skipped this discussion: are we planning to have human-readable IDs or set the BitField (like in the key4hep, idk whether geomodel provides it naturally)?

[olantwin]

I forgot to ask or maybe skipped this discussion: are we planning to have human-readable IDs or set the BitField (like in the key4hep, idk whether geomodel provides it naturally)?

This depends on the detector. Where possible having a simple scheme that's human readable would be nice, but a lot of detectors are quite complicated, so I don't think that will generally be possible. For most we'll probably want it to be a packed int struct with accessors that allow parsing it.

[amagnan]

Maybe I am completely out of the discussion there, but just want to check something for the logic: even if we simulate only one geometry "node", take e.g. the silicon plane for the SiPad in SND, we cannot possibly save all G4 hits to reconstruct whatever granularity we will need at the digitisation step. So, we have to fix some granularity for the simhits, and for this, I would have thought we want the same detID indexing as the digi and reco hits will have too basically (or more granular to assemble afterwards).
So is the distinction you make basically with "channel ID" the "electronics indexing" (by readout chip, cable to FED etc....) and "geometrical detID" which does not have to refer to a G4 volume, but is the separate unit by which we have access to position and E information anywhere in the detector, geometrically ?

[mesmith75]

I think we follow what FairShip does - one hit per entry/exit of an active volume

[matclim]

I would strongly advocate we follow what @mesmith75 suggests and produce a single hit per entry/exit of an active volume while staying clear insofar as possible from any cellID/BitField decodings which are a pain to debug and decode for little gain.

[amagnan]

So, I am very sorry if I misunderstand the situation, but I believe this is not always possible or we are creating too many volumes and the simulation is atrociously slow. So we have to separate active volume from detID (i.e. be able to break active volume into detIDs to record simhits per unique detid) , or at least give that possibility where it is important. Then, you may not use the detID immediately, but it is there for the subdetectors that need it ? But again maybe I misunderstand the discussion!

[olantwin]

Maybe I am completely out of the discussion there, but just want to check something for the logic: even if we simulate only one geometry "node", take e.g. the silicon plane for the SiPad in SND, we cannot possibly save all G4 hits to reconstruct whatever granularity we will need at the digitisation step.

I don't understand why not. We can save one hit per track or if we want even every single Geant4 interaction in a volume with the true position etc. We don't reply on the node ID for determining the position.

So, we have to fix some granularity for the simhits, and for this, I would have thought we want the same detID indexing as the digi and reco hits will have too basically (or more granular to assemble afterwards). So is the distinction you make basically with "channel ID" the "electronics indexing" (by readout chip, cable to FED etc....) and "geometrical detID" which does not have to refer to a G4 volume, but is the separate unit by which we have access to position and E information anywhere in the detector, geometrically ?

Again, we do not require a geometric ID to determine the true position.

[olantwin]

So, I am very sorry if I misunderstand the situation, but I believe this is not always possible or we are creating too many volumes and the simulation is atrociously slow. So we have to separate active volume from detID (i.e. be able to break active volume into detIDs to record simhits per unique detid) , or at least give that possibility where it is important. Then, you may not use the detID immediately, but it is there for the subdetectors that need it ? But again maybe I misunderstand the discussion!

The node ID would probably only be used to understand what macroscopic detector has seen a simhit, it is not needed for the position. For the digitisation, we'll probably use true position and energy deposits to decide which channels see how much, with the node ID deciding only which digitisation algorithm is appropriate.

[amagnan]

OK I think I finally understand, now you are really saving one object "simhit" per G4 track stepping into a given sensitive volume, so whether that volume is divided at geometry level or not will not change the number of information recorded, just they will all appear under the same "detectorID" and you can reorganise them into detector cells later. For the CMS HGCAL it would just completely explode your data volume, but for us it remains manageable it seems ? Still for showers in calorimeters it seems a very high level of data granularity ...