Flag clusters as EMCal or HCal

[ruse-traveler]

Briefly, what does this PR introduce?

This PR introduces two new flags to the Jug::Reco::ClusterType in algorithms/calorimetry/ClusterTypes, kClusterEMCal and kClusterHCal. These flags are intended to help facilitate generic algorithms downstream which need to distinguish between EM and hadronic energy.

These are new types are used to flag only the types of clusters which will be passed on to downstream, holistic algorithms such as the output of CalorimeterClusterRecoCoG (for all calorimeters other than the BIC) or EnergyPositionClusterMerger (for the BIC).

Note: this is intended to be an interim solution, aimed at facilitating development on downstream PF algorithms and maintaining momentum (see the presentation here for more details on the PF development plan). A longer-term, more flexible approach is discussed in EDM4eic#122.

What kind of change does this PR introduce?

• Bug fix (issue #__)
• New feature (issue Cluster EMCal vs. HCal flag #2086)
• 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?

No.

[github-actions]

Capybara summary for PR 2078

• 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-23T12:24-04:00 0959e87}}

[github-actions]

⚠️ Clang-Tidy found issue(s) with the introduced code (1/1)

No Clang-Tidy warnings found so I assume my comments were addressed

[wdconinc]

This isn't a mutually exclusive enumeration. What about an Ecal cluster makes it impossible to be a 2D or 3D cluster?

[ruse-traveler]

Correct! Ultimately, I think a longer-term, more flexible approach would be to treat the type as a bit field where we could turn on/off bits for 2D, 3D, EMCal, HCal, etc. I say a few words about this in EDM4eic#122.

My rationale in just extending the enum here rather than proceeding with the bit-field approach is that this is a minimal change that still satisfies what's needed for PFA3 (a generic way to identify EMCal vs. HCal clusters). This would allow for PF development to proceed in parallel with exploring better, long-term solutions.

[wdconinc]

I don't think we should be encoding Ecal vs Hcal clusters in the data type since it is accessible from the detector type in DD4hep, e.g. https://github.com/AIDASoft/DD4hep/blob/e369490a18a9857d5a61771f340c1791e8f9f7a3/DDCore/include/DD4hep/DetType.h#L53-L54

[ruse-traveler]

I don't think we should be encoding Ecal vs Hcal clusters in the data type since it is accessible from the detector type in DD4hep, e.g. https://github.com/AIDASoft/DD4hep/blob/e369490a18a9857d5a61771f340c1791e8f9f7a3/DDCore/include/DD4hep/DetType.h#L53-L54

Ah! I wasn't aware of this enum! Thanks! Based on a cursory glance, it seems like many of our calorimeters don't set these...

But then I'm curious about how I would use this downstream. For example, would I extract these from a cell ID? Or would I look them up based on the system ID? In the former case, I suspect I would need to select a hit from the cluster to identify a cell ID; and in the latter, I expect I would need to provide the system IDs to use as a parameter to the algorithm...

[wdconinc]

Ah! I wasn't aware of this enum! Thanks! Based on a cursory glance, it seems like many of our calorimeters don't set these...

Yeah, it's only imposed by ACTS for tracking, which is why those have it...

But then I'm curious about how I would use this downstream. For example, would I extract these from a cell ID? Or would I look them up based on the system ID? In the former case, I suspect I would need to select a hit from the cluster to identify a cell ID; and in the latter, I expect I would need to provide the system IDs to use as a parameter to the algorithm...

Cell ID would give you system ID as the 8 lsb. Presumably there is nothing in our data model that is so disconnected from hits that you can't get there in a hop or two.

If the use is for within EICrecon, then I'd prefer to not just add unspecific bit fields to data model. I don't know what it adds to the end user if they know it's a 2D vs 3D cluster. And within EICrecon at what point is there confusion about this, and does it matter? In any case, having to specify what an algorithm produces in its configuration seems redundant.

[ruse-traveler]

Gotcha! Makes sense! The use case I was imagining was primarily in EICrecon (e.g. as a cross-check in a topoclustering algorithm that expects to ingest only 2D clusters, or in algorithms where you need to divvy up energy by calorimeter type), but the EM/Had distinction was one that could be useful for downstream analysis...

Either way, if there's an easy way to extract it from DD4hep then we can just go with that! Just to check before opening a PR to add them: the EMCal and HCal DD4hep tags shouldn't impact the actual detector simulation, right? They're just there for description?

[wdconinc]

the EMCal and HCal DD4hep tags shouldn't impact the actual detector simulation, right? They're just there for description?

Should not impact simulation indeed. May impact overall event classification. This is used to indicate in an event bit pattern whether the event had any energy deposition in an Ecal or Hcal, but we don't do anything with that.