[bug] Off axis endcap with dd4hep plugin.

[whit2333]

Hello,

I get the following error when the "layer" volume associated with an "endcap" is offset from the z axis:

17:16:40    D2A_L:B0Trac   VERBOSE    Received layers for positive volume -> creating disc layers
17:16:40    D2A_L:B0Trac   VERBOSE    Disc layer has 12 senstive surfaces.
17:16:40    D2A_LAC        VERBOSE   Creating a disk Layer:
17:16:40    D2A_LAC        VERBOSE    - at Z position    = 5405.09
17:16:40    D2A_LAC        VERBOSE    - from Z min/max   = 5401.27 / 5408.41
17:16:40    D2A_LAC        VERBOSE    - with Z thickness = 9.99688
17:16:40    D2A_LAC        VERBOSE      - incl envelope  = 1.17385 / 1.6762
17:16:40    D2A_LAC        VERBOSE    - with R min/max   = 35 (-2.65614) / 150 (+137.582)
17:16:40    D2A_LAC        VERBOSE    - with phi min/max = -3.14159 / 3.13982
17:16:40    D2A_LAC        VERBOSE    - # of modules     = 12
17:16:40    D2A_SAC        VERBOSE   Creating a SurfaceArray on a disc
17:16:40    D2A_SAC        VERBOSE   Create equidistant binning Axis for binned SurfaceArray
17:16:40    D2A_SAC        VERBOSE   	BinningValue: 3
17:16:40    D2A_SAC        VERBOSE   	(binX = 0, binY = 1, binZ = 2, binR = 3, binPhi = 4, binRPhi = 5, binH = 6, binEta = 7)
17:16:40    D2A_SAC        VERBOSE   	Number of bins: 6
17:16:40    D2A_SAC        VERBOSE   	(Min/Max) = (35/150)
**************************************************** 
*  A runtime error has occured :                     
*    vector::_M_range_check: __n (which is 7) >= this->size() (which is 6)
*  the program will have to be terminated - sorry.   
**************************************************** 

I think we have hit the limit of the imposed barrel-endcap construction paradigm in the dd4hep plugin. The detector in this case is a far forward detector without a corresponding negative endcap. (Perhaps this endcap pair requirement should be the first to go in upgrading the dd4hep plugin?) So, I added a negative endcap to get the plugin functioning, but only the positive endcap is offset from the z axis.

Here are the verbose outputs for two configurations:

• Tracker layer centered on z axis: https://eicweb.phy.anl.gov/EIC/detectors/athena/-/jobs/222479
• Tracker slightly offset from z axis: https://eicweb.phy.anl.gov/EIC/detectors/athena/-/jobs/222615

[whit2333]

@asalzburger is this a known limitation?

[paulgessinger]

This looks like a failure in the binning. This is a bit weird since the bin lookup should be safe, i.e. it shouldn't try to get bin number 7 when there are only 6 bins. Maybe the binning logic makes some wrong assumptions when the layers are not (approximately) on axis? Would it be very difficult for you to run this through a debugger to find out where exactly it's doing the out-of-bounds access here, @whit2333?

I guess the problem with the endcap configuration assumptions is that it is surprisingly difficult to automate the volume glueing and dimension-synchronization logic without these assumptions. The general fallback to this is to fall back to manually setting up, synchronizing and glueing the volumes together where necessary. (We do this for the ATLAS ACTS geometry to some extent).

[whit2333]

@paulgessinger is the binning a feature that is used for tracking or is it just used for hit/channel generation? For our purposes, AFAIK, we only need "surfaces" and "volumes". We construct the covariance matrix using information from dd4hep's segmentation.

Perhaps, it is just confusion on my part regarding the jargon.

For the debugging, I can maybe help pin point the problem if you can direct me towards the relevant binning code.

[paulgessinger]

The binning that this is referring to here is the layer binning which is used to lookup sensor surfaces for an intersection with the layer surface during navigation. In theory a single bin can be used here, which will slow down navigation a bit because a larger number of sensors have to be tried.

[whit2333]

Good to know. Thanks.

[paulgessinger]

Is there any way you could provide more information on the geometry construction. It's pretty difficult to diagnose what might be root problem here with just this log. Can you provide the full log file again, I think the one you linked might have expired, or are otherwise inaccessible to me.

Could you also briefly describe the endcap geometry again to me? Are the disks all off-axis? How many sensors are there on the disks, and how are they arranged roughly?

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.

[AJPfleger]

Hi @whit2333, it has been a while and a lot of changes of been done to the geometry and the binning. Do you remember, if this issue was resolved or could you still reproduce the problem?

[github-actions[bot]]

This issue/PR has been automatically marked as stale because it has not had recent activity. The stale label will be removed if any interaction occurs.