12-Sector CyMBaL

[ybedfer]

Briefly, what does this PR introduce? Please link to any relevant presentations or discussions.

12-Sector CyMBaL, aiming at simplifying maintenance, see e.g. "https://indico.bnl.gov/event/28403"

What is the urgency of this PR?

• [*] Medium

What kind of change does this PR introduce?

• [* ] New feature (no related issue ever created)

Please check if any of the following apply

None

[ybedfer]

This is the second one of the series of PRs meant to commit a 12-sector version of CyMBaL.
Needs EICrecon PR #2829 "eic/EICrecon#2829".

The 12-sector layout has a fish scale structure that allows to have a unique model of module in all four sections along Z.
=> This greatly simplifies the design of the XML and detector builder, which are hence completely reshuffled.

Here is a picture of the layout, w/ its 12 sectors.:

(There are two distinct sets of 12 sectors in the above picture: they correspond to the projections of the inner and outer Z-sections, the latter being shifted outwards along the bisector of the sectors, so that the sections do not overlap.)

The new version has a more detailed and realistic specification of the stack-up. It's based on the following list parameters (provided by Damien Neyret):

 [stack-up Geico_v7.pdf](https://github.com/user-attachments/files/30742247/stack-up.Geico_v7.pdf)

  // parameters
  ZActiveX = 340; ZActiveY = 590;  // size of active area
  nbStrX = 192, nbStrY = 576; // nb de voies
  pitchX = 1.766; pitchY = 1.021;  // pitch en X et Y
  sizeStrX = 0.7; sizeStrY = 0.9;  // taille de l'aperture des pistes, carré size X size
  gapEndStrip = 1; // gap between end of strips and side of active area

 Il y a aussi le quadrillage de masse au-dessus de la dérive mais c'est assez peu dense, pitch 
2,4mm avec des pistes de 200µm de large (dans les 2 directions U et V). A ce moment il y a 
aussi le quadrillage de masse sur le plancher, pitch 800µm et pistes de 200µm dans les 2 
sens.

The new stack-up contains more material than the previous version. See the following plot of %X0 as a function of θ, where new is red and old is blue:

(Note that in the new version the services to the inner section are not included: explains why on the edge, red lies below blue.)

Below plots of the distributions of SimHit and RecHit-SimHit residuals:


(They can be compared to those attached to PR #2829 of EICrecon ("eic/EICrecon#2829"), obtained w/ the older, 8-sector version. => in particular, the new resolutions, which differ in φ (=260 μm) and Z (=159 μm) and the new overlaps along both φ and Z are found to be wider: they stick out more, in black, over the rest of the distributions. The resolutions are defined as constants in the XML, from where they are converted into configuration parameters by the MPGD plugin. This, if available, default being 150 μm.)

Another feature of the new version is the DeadZone lining the PCB on all four sides. Here is a picture of the resulting RecHit distribution:

=> The region devoid of hits corresponds to the distance between the edge of the PCB and the centre of the closest strip = 1 mm of DeadZone + half-strip width. This, because digitization cannot but make so that hits w/in the corresponding half-pitch have a cluster size of 1 and all sit at the centre of the strip. The first non empty bin of the histogram has about the same content as the rest, despite its narrow width (of a half-pitch), as expected for an approximately uniform distribution of incoming SimHit. hasDeadZone is yet another configuration parameter, which is set = true for CyMBaL by the MPGD plugin, and hence also modifies, very slightly, the working of the 8-sector CyMBaL.

[ybedfer]

stack-up Geico_v7.pdf

[ybedfer]

Hit-to-Track association (barrel MPGDs are subdivided in 'p', 'n' and 'p&n' sub-bins, 'p' being 'φ' or 'U' and 'n' being 'Z' or 'V'):

=> The association efficiency of 12SCyMBaL looks reasonable: it's as good as that of the Outer MPGD, slightly worse still than that of the rest of the barrel trackers.

=> CyMBaL, which is the next to most outward detector (on this picture there is no TOF), displays a discontinuity in radius when one moves from the outer Z-sections to the inner ones: this translates the outward shift applied to the outer sections mentioned supra (the actual radius of curvature is the same for all sections).

(Note that I have had to edit the hit_matching macro (see "https://github.com/eic/snippets/blob/main/Tracking/TrackHitContributions/hit_matching.C") to get the above plots. This, because for some reason, I do not get TOF RecHit from my execution of eicrecon. Here is the patch:

diff --git a/Tracking/TrackHitContributions/hit_matching.C b/Tracking/TrackHitContributions/hit_matching.C
index 1009dfc..2ae4f74 100644
--- a/Tracking/TrackHitContributions/hit_matching.C
+++ b/Tracking/TrackHitContributions/hit_matching.C
@@ -262,3 +262,9 @@ void hit_matching(int verbose = 0, int nEvtMx = 0){
        //...making room for two indices for the 2DStrip MPGDs.
+#define EXCLUDE_TOF
+       // if "TOFBarrelRecHits" and "TOFEndcapRecHits" are absent.
+#ifdef EXCLUDE_TOF
+       size_t nRecColls = 7;
+#else
        size_t nRecColls = rec_coll_names.size();
+#endif
        for (size_t i = 0; i < nRecColls; i++) {
@@ -463,3 +469,8 @@ void hit_matching(int verbose = 0, int nEvtMx = 0){
                        cout<<"Number of SimHit collections = "<<sim_coll_names.size()<<endl;
-               for(int icoll = 0; icoll < (int)sim_coll_names.size(); icoll++){
+#ifdef EXCLUDE_TOF
+               size_t nSimColls = 7;
+#else
+               size_t nSimColls = sim_coll_names.size();
+#endif
+               for(int icoll = 0; icoll < (int)nSimColls; icoll++){
                        //SimHits
@@ -511,3 +522,3 @@ void hit_matching(int verbose = 0, int nEvtMx = 0){
                }
-               for(int icoll = 0; icoll < (int)rec_coll_names.size(); icoll++){
+               for(int icoll = 0; icoll < (int)nRecColls; icoll++){
                        //RecHits
@@ -612,3 +623,7 @@ void hit_matching(int verbose = 0, int nEvtMx = 0){
                //Loop over Measurement2D hits (independent of track reconstruction)
+#ifdef EXCLUDE_TOF
+               auto& meas2d_coll = f.get<edm4eic::Measurement2DCollection>("CentralWithoutTOFTrackerMeasurements");
+#else
                auto& meas2d_coll = f.get<edm4eic::Measurement2DCollection>("CentralTrackerMeasurements");
+#endif
                //Book keeping of MPGD strip hits.

And I removed TOF from my epic_craterlake_tracking_2DStrip configuration.)