EcalBarrelScFiProtoClusters: use localDistXY instead of localDistXZ

[wdconinc]

Briefly, what does this PR introduce?

The island clustering in the BEMC EcalBarrelScFiProtoClusters should happen in the XY plane, not the XZ plane. This should remove the unreasonable effectiveness of the island clustering for two gammas in the same sector. We only gain Z information when we add timing analysis, and we don't lose the Y information at that point but combine it all in topological clustering.

What kind of change does this PR introduce?

• Bug fix (issue: EcalBarrelScFiProtoClusters unreasonably effective)
• New feature (issue #__)
• Documentation update
• Other: __

Please check if this PR fulfills the following:

• Tests for the changes have been added
• Documentation has been added / updated
• Changes have been communicated to collaborators

Does this PR introduce breaking changes? What changes might users need to make to their code?

No.

Does this PR change default behavior?

Yes, makes EcalBarrelScFiProtoClusters worse.

[github-actions]

Capybara summary for PR 2094

• rec_dis_10x100_minQ2=0_craterlake_10x100
• rec_dis_10x100_minQ2=1000_craterlake_tracking_only
• rec_dis_18x275_minQ2=0_craterlake_18x275
• rec_dis_18x275_minQ2=0_craterlake_18x275_MT
• rec_dis_18x275_minQ2=0_craterlake_18x275_ST_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275
• rec_dis_18x275_minQ2=1000_craterlake_18x275_MT
• rec_dis_18x275_minQ2=1000_craterlake_18x275_ST_MT
• rec_dis_5x41_minQ2=0_craterlake_5x41
• rec_e_1GeV_20GeV_craterlake
• rec_pi_1GeV_20GeV_craterlake
  ^{_{Last updated 2025-09-29T16:28-04:00 3058a47}}

[veprbl]

Do I understand correctly, that Y is the radial direction? I'm not entirely sure what is the effect is being fixed or worked around here. Ultimately, we want XZ, but the artificial Z segmentation is not representative of the resolution?

[wdconinc]

Do I understand correctly, that Y is the radial direction? I'm not entirely sure what is the effect is being fixed or worked around here. Ultimately, we want XZ, but the artificial Z segmentation is not representative of the resolution?

Island clustering for the scfi should have as primary directions X and Y (i.e. the tangential and radial directions at the end of sector readout plane*). The Z information is only secondarily available (since it requires time info, and then resolving which pulses on both ends are matching the same original hit). We therefore don't want Z information in our island clustering (which is 2D only).

Right now we are ignoring radial direction entirely when doing the clustering, and instead we are using Z information which is leading to a too optimistic operation.

So, this will make scfi clustering intentionally worse since we are now applying clustering in a way that is unrealistically efficient for same-sector clusters.

[sly2j]

I think there's a bit of a misunderstanding: In local coordinates, the fibers are in the y-direction and the grid cells are in the x-z plane (similar to the tracker disks). See for example here: https://github.com/eic/epic/blob/fc2eb7a5f35264d46c5c5c04e0404e3b816b8e82/src/BarrelCalorimeterScFi_geo.cpp#L279C50-L279C51

In other words, we shouldn't change this as this would break what the algorithm is supposed to be doing.

[wdconinc]

I think there's a bit of a misunderstanding: In local coordinates, the fibers are in the y-direction and the grid cells are in the x-z plane (similar to the tracker disks). See for example here: https://github.com/eic/epic/blob/fc2eb7a5f35264d46c5c5c04e0404e3b816b8e82/src/BarrelCalorimeterScFi_geo.cpp#L279C50-L279C51

In other words, we shouldn't change this as this would break what the algorithm is supposed to be doing.

You can print out the positions it operates on to see that the local position is not rotated, only shifted.

[wdconinc]

You can print out the positions it operates on to see that the local position is not rotated, only shifted.

And there's the fact that for events with two gammas in the same sector we somehow identify two clusters with scfi island clustering, which shouldn't be possible. This change reverts that back to reconstruction of a single cluster, as it should be if we don't use the z segmentation.

[wdconinc]

Here are the input x and y local coordinates for EcalBarrelScFiRecHits:

And here is the z local coordinate:

(sorry for splitting, they are on different rows in capybara) (these are rec_dis_18x275_minQ2=0_craterlake_18x275)

These are not local in the sector coordinate system anymore. As discussed with @sly2j on mm, there is possibly a change in the geometry that caused this, e.g. a change from placing an actual sector volume to placing fibers in an assembly. I can't find anything while blame surfing epic.

We (=I) should get back to adding the capybara output to the epic repository, so we capture these issues, if it is a geometry change.

The other possible cause could be in our global-to-local handling in CalorimeterHitReco which may have started to use a different reference volume. I don't see any relevant changes to that in a long time, so I don't know what could have changed.

[sly2j]

Interesting, I wonder what changed and how long the algorithm has been wrong. From your figures I agree that XY is the correct plane to use here. I retract my previous objection. We should also fix the comments in the geometry implementation so we avoid future confusion.

[veprbl]

Not sure if this or #2107 is intended

[wdconinc]

Not sure if this or #2107 is intended

If we have to pick something now, then this is better than nothing. #2107 doesn't work yet and the patient needs diagnosis.