You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
HcalDetectorMap reads a hand made csv file, and produces a map between electronics IDs and digi IDs. Currently, some things in there are hard-coded for the specific cabling at the 2022 test beam.
Other thoughts:
When we look at channels in the second chip half, we starting counting from channel 0 again instead of calling it channel 36. Is this necessary? Do the electronic IDs require this convention? The HGCROC chip configuration indexes channels from 0 to 71, and it would have saved me some confusion if we did the same. If possible, I would rather that the RawDecoder translates channels from the 0 - 35 range into 0 - 71, so that a user never has to see two different conventions.
In our connections file we number bars starting from 1, while in our digiIDs we start from 0 :(
The flag want_d2e, to build a reverse detector->electronics map, doesn't do anything at the moment.
Describe the solution you'd like
This code doesn't do a whole lot, most of the mapping is already present in the connections csv file. Maybe all of this could stored in the csv from the very beginning, e.g. mapping channels to what link they are on, the bar numbering, what end a channel is on etc. Thus removing all detector-specific mapping logic in this class.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
HcalDetectorMap reads a hand made csv file, and produces a map between electronics IDs and digi IDs. Currently, some things in there are hard-coded for the specific cabling at the 2022 test beam.
Other thoughts:
When we look at channels in the second chip half, we starting counting from channel 0 again instead of calling it channel 36. Is this necessary? Do the electronic IDs require this convention? The HGCROC chip configuration indexes channels from 0 to 71, and it would have saved me some confusion if we did the same. If possible, I would rather that the RawDecoder translates channels from the 0 - 35 range into 0 - 71, so that a user never has to see two different conventions.
In our connections file we number bars starting from 1, while in our digiIDs we start from 0 :(
The flag want_d2e, to build a reverse detector->electronics map, doesn't do anything at the moment.
Describe the solution you'd like
This code doesn't do a whole lot, most of the mapping is already present in the connections csv file. Maybe all of this could stored in the csv from the very beginning, e.g. mapping channels to what link they are on, the bar numbering, what end a channel is on etc. Thus removing all detector-specific mapping logic in this class.
The text was updated successfully, but these errors were encountered: