Opposite channel numbering sorting for OpDets
The convention used to assign channels numbers to OpDets is (mostly) opposite to any other.
Function in question is
if(xyz1!=xyz2) return xyz1>xyz2; else if(xyz1!=xyz2) return xyz1>xyz2; else return xyz1>xyz2;
means that the channel number increases with decreasing Z, Y or X; in that order of priority
To better coincide with the other sorter algorithms and a more natural convention it should be:
if(xyz1 != xyz2) return xyz1 < xyz2; else if(xyz1 != xyz2) return xyz1 < xyz2; else return xyz1 < xyz2;
Note that I changed the inequality sign.
With that change it will become: the channel number increases with increasing Z, Y or X; in that order of priority
Obviously I understand the implications of making this change, and that it will break more things than the potential issues it might prevent. I'm mostly highlighting this to make this discrepancy evident for others.
#2 Updated by Gianluca Petrillo about 2 months ago
One additional information: the channel number is assigned by LArSoft in contiguous blocks, first to the first cryostat (
C:0, then to the second
C:1 and so on). Within the cryostat, channels are assigned in the same order as the optical detectors are sorted within the cryostat, which is the reason why
geo::GeoObjectSorter::SortOpDets() affects also the channel mapping.
Also note that both the original and the suggested sorters have a strange effect on cathode-in-the-middle TPC: optical detectors on one drift volume are assigned only odd channel numbers, while the ones on the opposite drift volume will be assigned only even ones. ICARUS has moved away from that (at the cost of unspeakable pain).
I add as an annotation that I am surprised that such a rounding-error-sensitive algorithm has not created weird jumps.