Feature: additional `DetType`s for backward and far detectors

[ruse-traveler]

Recently, in epic#994 we were working on adding appropriate DetType tags to subsystems missing them in ePIC. We noticed that the list of DetType doesn't fully capture the features of the ePIC detector, namely that:

• Since the EIC is an asymmetric collider, we distinguish FORWARD and BACKWARD; and
• We have subsystems that are several meters downstream from the central detector which aren't really part of the BARREL or ENDCAPs.

Being able to flag these regions would be very useful for us, and the existing DetectorTypeEnumeration could be easily extended to accommodate them (e.g. below).

While the primary consumer of these would likely just be the EIC for now, these flags could be useful for studies of other potential asymmetric colliders or for far-forward upgrades to existing detector concepts. A few examples of future asymmetric colliders might be the LHeC, FCC-eh, and (maybe) a muon collider run in an asymmetric mode.

    /// Different detector type flags
    enum DetectorTypeEnumeration {
      IGNORE          = 0 ,
      TRACKER         = 1 <<  0, 
      CALORIMETER     = 1 <<  1, 
      CHERENKOV       = 1 <<  2, 
      ENDCAP	      = 1 <<  3, 
      BARREL          = 1 <<  4, 
      FORWARD	      = 1 <<  5, 
      VERTEX	      = 1 <<  6, 
      STRIP	          = 1 <<  7, 
      PIXEL	          = 1 <<  8, 
      GASEOUS  	      = 1 <<  9, 
      WIRE	          = 1 << 10, 
      ELECTROMAGNETIC = 1 << 11, 
      HADRONIC	      = 1 << 12, 
      MUON	          = 1 << 13, 
      SUPPORT         = 1 << 14,
      BEAMPIPE        = 1 << 15, 
      COIL            = 1 << 16,
      AUXILIARY       = 1 << 17,
      BACKWARD        = 1 << 18,
      FAR             = 1 << 19
   };

[andresailer]

If you are asking whether you can add two enums? Yes, please open a PR.

Also update DDDetectors/compact/detector_types.xml, please.

(Just as an aside: For CLIC, ILC, we have used "forward" to mean along the beampipe (Lumical, Beamcal, LHCal). So I can see that becoming ambiguous with 'backward' existing as well. Not sure we should just leave this up to whomever to keep it consistent, or propose a different enum to identify forward/backward-ness in the asymmetric case. Differentiation between forward and backward is done mostly via the cellID side bit, but that doesn't make sense if you have different detectors in the two directions)

[ruse-traveler]

If you are asking whether you can add two enums? Yes, please open a PR.

Also update DDDetectors/compact/detector_types.xml, please.

(Just as an aside: For CLIC, ILC, we have used "forward" to mean along the beampipe (Lumical, Beamcal, LHCal). So I can see that becoming ambiguous with 'backward' existing as well. Not sure we should just leave this up to whomever to keep it consistent, or propose a different enum to identify forward/backward-ness in the asymmetric case. Differentiation between forward and backward is done mostly via the cellID side bit, but that doesn't make sense if you have different detectors in the two directions)

Apologies for the (extremely) delayed response! But sounds good! I've opened #1573 to start implementing things.

I agree that this could get confusing switching between contexts... So if we did add a 2nd enum, would it something like this?

    /// Different detector type flags
    enum DetectorTypeEnumeration {
      /* left as is */
    };

    /// Directionality flags for asymmetric colliders
    enum DetectorDirection {
      NONE     = 0,
      FORWARD  = 1 << 0,
      BACKWARD = 1 << 1,
    };