Add missing detector type flags

[ruse-traveler]

Briefly, what does this PR introduce?

This PR adds DD4hep DetType flags to all sensitive detectors and to beampipes. 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 since only FORWARD is defined as a flag, I opted to label the FF/FB elements as ENDCAP. Then, following what was done in the central tracker, only detectors and beampipes are labeled; support and other structures are not.

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...)

[veprbl]

Should we propose DetFlag_FAR? To be used as DetFlag_FAR + DetFlag_FORWARD.

[ruse-traveler]

Should we propose DetFlag_FAR? To be used as DetFlag_FAR + DetFlag_FORWARD.

I think that also makes sense! It definitely would be useful to be able to distinguish between detectors that are physically in the endcap vs. those that are along the beamline.

[veprbl]

Acts is not happy with this one:

22:50:50    Acts           VERBOSE   --> Layer candidate match: VertexBarrel_layer\d -> VertexBarrel_layer2
22:50:50    Acts           VERBOSE   Volume: 'VertexBarrelSubAssembly' is a compound volume -> resolve the sub volumes

[ruse-traveler]

Acts is not happy with this one:

22:50:50    Acts           VERBOSE   --> Layer candidate match: VertexBarrel_layer\d -> VertexBarrel_layer2
22:50:50    Acts           VERBOSE   Volume: 'VertexBarrelSubAssembly' is a compound volume -> resolve the sub volumes

Hmmm... I'm also seeing a bunch about the tagger :/

22:50:50    Acts           INFO      Translating DD4hep sub detector: Tagger2
22:50:50    Acts           VERBOSE   Processing detector element:  Tagger2
22:50:50    Acts           VERBOSE   SubDetector type is: [DetType( 0x9) : TRACKER, ENDCAP, ], compound: no
22:50:50    Acts           WARNING   Subdetector with name: 'Tagger2' has inconsistent information for translation and is not of type 'compound'. If you want to have this DetElement be translated into the tracking geometry you need add the right DetectorType or VariantParameters (at this stage the subvolume needs to be declared as BEAMPIPE or BARREl, or have a VariantParameter passive_layer=true) or if it is a compound DetElement (containing a barrel-endcap hierarchy), the type needs to be set to 'compound'.

[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.

[wdconinc]

I'm suspicious of these changes. Why would there only need to be a compound type for one of these assemblies?