Imaging Calorimeter CellID fields

[jml985]

In 23.12.0 using craterlake the imaging calorimeter cellId is set as:

system:8,sector:6,layer:6,slice:4,grid:10,fiber:16,z:-14

I see layers: 1,3,4,6, but also 17,19,20,22,33,35,36,38,49,51,52,54 in the data I also see fiber values: 0-5, but also 16379-65535

These seem odd, but I don't know if they are a bug or not.

[jml985]

There is a similar problem in 23.12.0 craterlake for the EcalBarrelScFi calorimeter. Here is the id is:

system:8,sector:8,row:8,tower:-8

But this leads to 240 sectors with row # between 16-19. The correct id should be

system:8,sector:6,row:6,something:2,tower:8

Which gives 48 sectors and 12 rows, as the detector seems to be layed out

[mariakzurek]

Hi @jml985, I cannot reproduce the issue. What data are you using? Can you point me to the file on S3.

The EcalBarrelSciFi ans EcalBarrelImaging hits have the following cellIDs https://github.com/eic/epic/blob/main/compact/ecal/barrel_interlayers.xml#L322:

  <readouts>
    <readout name="EcalBarrelImagingHits">
      <segmentation type="CartesianGridXY" grid_size_x="0.5 * mm" grid_size_y="0.5 * mm"/>
      <id>system:8,sector:6,layer:4,stave:4,module:8,slice:2,x:32:-16,y:-16</id>
    </readout>
    <readout name="EcalBarrelScFiHits">
      <segmentation type="CartesianStripZ" strip_size_x="1.0*cm" identifier_x="z"/>
      <id>system:8,sector:6,layer:6,slice:4,grid:10,fiber:16,z:-14</id>
    </readout>
  </readouts>

The only change to those lines was about 7 months ago when we changed naming from module to sector: https://github.com/eic/epic/commit/c7942d994320e3e13f728968660993bd3ea6c5bc#diff-fe516063940ca32b71bfe6f3ad88d633bdf97d7e2c92a996119b47a1d38b487fL224-L234

BIC does not have towers. The system:8,sector:8,row:8,tower:-8 was set for SciGlass calorimeter if I remember correctly @veprbl. Are you sure you are using most up to date epic geometry?

ImagingRecoHits layers can have nb: 1-3-4-6, and they don't have fibers. SciFiRecoHits layers are 1-12. They both have 48 sectors. I plot below the data from the official single particle production with 23.12.0: eictest/EPIC/RECO/23.12.0/epic_craterlake/SINGLE/e-/1GeV/45to135deg

[wdconinc]

I don't know if this is relevant, but I've wasted time on ad hoc analyses of cellID decodings before due to a bug in ROOT that doesn't read unsigned long ints correctly under certain conditions. See https://github.com/root-project/root/issues/7844 for some details.

[wdconinc]

@jml985 Is this issue still vexing you? Before the 24.04 campaign we should verify that the data is indeed looking like it should.

Based on the automatically generated plots at https://eicrecon.epic-eic.org/pr/1354/capybara/rec_dis_18x275_minQ2=1000_craterlake/index.html#EcalBarrelScFiRecHits and https://eicrecon.epic-eic.org/pr/1354/capybara/rec_dis_18x275_minQ2=1000_craterlake/index.html#EcalBarrelImagingRecHits the sector and layer numbers look fine for both scfi and imaging detectors. These are autoscaled to min/max range, so that indicates that in those 100 events there are no hits that result in layers > 6 for the imaging detectors. For RecHits fiber is not filled.

If this is not an issue anymore, please feel free to close it.