Silicon disks 3,4,5 in N and P direction must have offset hole

[wdconinc]

Is your feature request related to a problem? Please describe. The silicon tracker disks at the expanding incoming and outgoing beampipe must have a hole that is off-centered.

Describe the solution you'd like In the xml file we should add parameters for the offset, e.g. TrackerEndcapNLayer4_offsetx, and pass them to the envelope, e.g.,

        <envelope vis="TrackerLayerVis"
          rmin="TrackerEndcapNLayer4_rmin"
          rmax="TrackerEndcapNLayer4_rmax"
          offsetx="TrackerEndcapNLayer4_offsetx"
          length="SiTrackerEndcapLayer_thickness"
          zstart="TrackerEndcapNLayer4_zmin" />

and we would need to add support to the src/TrapEndcapTracker_geo.cpp, such as:

    std::string layer_vis      = l_env.attr<std::string>(_Unicode(vis));
    double      layer_rmin     = l_env.attr<double>(_Unicode(rmin));
    double      layer_rmax     = l_env.attr<double>(_Unicode(rmax));
    double      layer_offsetx  = l_env.attr<double>(_Unicode(offsetx));
    double      layer_length   = l_env.attr<double>(_Unicode(length));
    double      layer_zstart   = l_env.attr<double>(_Unicode(zstart));
    double      layer_center_z = layer_zstart + layer_length / 2.0;
// ...
    Tube   layer_tub_outer(0, layer_rmax, layer_length / 2);
    Tube   layer_tub_inner(0, layer_rmin, layer_length / 2);
    SubtractionSolid layer_tub(layer_tub_outer, layer_tub_inner, Translation3D(layer_offsetx, 0, 0));

Describe alternatives you've considered Keep larger central hole, but that cuts into acceptance.

Additional context There will additional work needed to then place the rings correctly. Maybe we need to add a phi range for the rings, or otherwise allow for incomplete rings.

[wdconinc]

Maybe @sly2j has some ideas of how this should be approached.

[ShujieL]

I checked with Ernst on the disk geometry, we will need to make the disk itself centered along z but the inner hole off-centered to accommodate the beampipe. In this case, do you see any big difference in the work involved to make those off-centered hole with our current approach (slices in phi to assemble disk) vs. a more realistic approach ( build disk from actual tile/strips) ? @sly2j @wdconinc

[wdconinc]

Yes, it will be a lot more work to build it from strips and tiles. But that work needs to happen. Probably not before October, though. I think some of the helper functions in the calorimeter endcaps may be useful.

[smaple1]

I'll begin working on this issue :)

[ShujieL]

As suggested by the ACTS developer (Andi), we will assemble the disks with blocks/staves instead of trying to create a simplified geometry of "disks with offset holes", which turned out to require same level of implementation effort. Stephen is working on it.

[smaple1]

There's been some work on this, which is available on my fork https://github.com/smaple1/epic/tree/smaple-disk-tiling .

The main change is the creation of a "TileEndcapTracker_geo.cpp" module, which replaces the TrapEndcapTracker currently being used. There are however a couple of outstanding issues that need attention:

1. The geometry construction occurs in two parts: envelope, and tile-like modules. My understanding is that the envelope is what ACTS sees -> in the TrapEndcapTracker the envelope is a cylinder, which is a shape that ACTS is happy with, which is then populated by trapezoidal modules. In the TileEndcapTracker, if there is no x offset this can be done the same way, with a cylindrical envelope (it's a matter of commenting and uncommenting a few lines of code) and everything works fine with ACTS, however when we add in the x-offset we can no longer use a cylinder for the envelope -> the issue is that the new shape I have created for the envelope (a cylinder with offset hole) is not recognised by ACTS so errors occur during the EICrecon stage. The npsim stage works in either case.
2. An easier to resolve second problem: the x_offsets for the disks need to be defined in the relevant compact files. I defined these in the silicon_disks.xml file -> this is universal to all versions of epic, which is a problem as the disks are not in the same z position for all versions of epic and so have different required x_offsets. This can simply be resolved by moving the x_offset declarations in the silicon_disks.xml file to the relevant definitions files (definitions.xml for pre craterlake disk positions, definitions_craterlake.xml for craterlake and beyond).

I am now writing up my thesis and will not have time to work on this for a while.

[wdconinc]

I am now writing up my thesis and will not have time to work on this for a while.

@ShujieL Can you make sure this gets picked up and merged into main?

[ShujieL]

As a proof of principle, I created a test geometry with vertex barrels and two endcaps. Because only the central beampipe defined as ACTS volume, I was able to create an upstream disk (layer) volume (which is virtual and generated by ACTS automatically) that overlaps with the upstream beampipe material in DD4hep, then place tiles in the disk volume without overlap with any dd4hep materials.

The code is updated at https://github.com/eic/epic/tree/si_disk_hole.

This configuration passed overlap check, and went through DD4hep and EICrecon without issue. This means we no longer need to deal with the disk geometry with off-center hole, the existing ACTS radial surface should work, as long as we don't have volume boundary overlap between disk and central beampipe.

Once we have a layout of disks with tiles, we can expand this plugin to have the full disk description.

@mposik1983 this should work for MPGD disks as well.