Add missing detector type flags

[ruse-traveler]

Briefly, what does this PR introduce?

This PR adds appropriate DD4hep DetType flags to all calorimeters missing them. An example of how to extract these flags from calorimeter and tracker hits (where the latter includes PID output) is provided in snippets here.

Note that when this PR was opened, there was no FAR flag defined, and so I opted to label the FF calorimeters as ENDCAP. However, DD4hep#1573 adds this (alongside BACKWARD). We should follow up to add these once we pick up this DD4hep version.

What kind of change does this PR introduce?

• Bug fix (issue Set DetType_{ELECTROMAGNETIC, HADRONIC} flags #993 )
• 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?

No.

[veprbl]

Have you tested querying these values? I don't think this works without explicit calls to dd4hep::xml::setDetectorTypeFlag() in each constructor.

[ruse-traveler]

Have you tested querying these values? I don't think this works without explicit calls to dd4hep::xml::setDetectorTypeFlag() in each constructor.

Oof! I haven't tried it out yet, but I'll report back when I do! If need be, I'll do a pass to add explicit calls where needed...

[ruse-traveler]

Have you tested querying these values? I don't think this works without explicit calls to dd4hep::xml::setDetectorTypeFlag() in each constructor.

Confirmed: you do indeed need an explicit call in each constructor. I just pushed a round of commits to add these calls to all sensitive detectors.

I also now have a working example of how to extract the type flags during reconstruction/analysis. I'll do a pass with it to make sure I've haven't missed/messed up anything, and then post here and add the example to either snippets or benchmarks...

[ruse-traveler]

It took a minute to work through it, but it looks like things are working mostly as expected! For some reason, the type flags don't seem to be propagated for the DIRC, pfRICH, FHCal insert, and far backward detectors. I haven't figured out why yet...

[wdconinc]

Note that since only FORWARD is defined as a flag

Can you consider if it makes sense to upstream an addition to dd4hep? Symmetric colliders have forward in both directions, so this is EIC-inspired but in some sense of broader relevance too (for all those other asymmetric colliders in development.......).

[ruse-traveler]

Note that since only FORWARD is defined as a flag

Can you consider if it makes sense to upstream an addition to dd4hep? Symmetric colliders have forward in both directions, so this is EIC-inspired but in some sense of broader relevance too (for all those other asymmetric colliders in development.......).

Yeah! I definitely think it makes sense upstream it to dd4hep! I suppose the FCC-eh proposal (or LHeC) might some other big use cases 🤷

(Though I also read a fun paper about running a muon collider with asymmetric beam energies a little bit ago...)

[ruse-traveler]

All right! I think I squashed the ACTS warnings with the latest round of commits (thanks to some help from Copilot), and also resolved the merge conflict. This should be ready for another review!

[veprbl]

Marking irrelevant detectors as beampipe (itself) messes with Acts geometry conversion.

[ruse-traveler]

Descoping to only add calorimeter tags.

[ruse-traveler]

Descoping to only add calorimeter tags.

[ruse-traveler]

Following up on the discussion yesterday in the Reco WG meeting, I've descoped the PR to only add calorimeter tags. I've checked that the relevant tags are being applied correctly (see the attached plots here), but I'm seeing the check-tracking-geometry (epic_craterlake) is failing with this error:

20:16:52    Acts           VERBOSE   Volume: 'EcalBarrelTrackerSubAssembly' is a compound volume -> resolve the sub volumes
terminate called after throwing an instance of 'std::logic_error'
  what():  Barrel was already given for this hierarchy! Please create a new DD4hep_SubDetectorAssembly for the next hierarchy.

Which I don't quite understand, since the changes now should only calorimeter tags...

[veprbl]

Perhaps, this is because BIC is also a tracking detector.

[ruse-traveler]

Perhaps, this is because BIC is also a tracking detector.

Yeah, that was it 🫤 I was getting into hot water with the setTypeFlag(...) calls in src/BarrelCalorimeterImaging_geo.cpp. I reverted those changes, and confirmed that test_ACTS.cxx runs successfully on craterlake after the reversion. I think we can live with the AstroPix hits not having a type for now.

In the process, I caught that (1) I wasn't propagating the type flags through to the BIC ScFi hits, and (2) I hadn't updated the newer FEMC files. After doing that, I'm seeing the correct types everywhere I would expect them! From my side, I think this is ready to go.

[veprbl]

LGTM