Zones are the upper and lower part of SciFi layers, which are reasonable to look at from the tracking perspective, however, alignment will happen at largest for half layers split in A and C side and the corresponding modules (and mats). A possible solution is to move to quarters instead of zones. This requires:
replace the ZoneHandler(Cache) by an equivalent for quarters
adapt PrForwardTracking
adapt PrHybridSeeding
!3565 (merged) is implementing this and already found that the impact is non-negligible for the tracking performance.
Yes, Allen does use the zones. In the forward tracking, search windows are opened within the zones and then triplets are created from hits of the same zones. In the seeding it also looks like the hit containers are filled by zone.
but does Allen also use positions of the zones themselves? because that's the problem in HLT2, we cache z, dx/dy, dz/dy of the zones to use them instead of the information from the hits
to give a bit more context, the values in the cache do not change with alignment:
Zone
Cache Z
Mat-level Z (example)
0
7826.1
7824.6
1
7826.1
7825.59
20
9333.1
9331.03
Zone
Cache dx/dy
Mat-level dx/dy (example)
0
0.00015414
0.000304435
1
0.00015414
-0.00033258
18
0.0876488
0.0880309
20
-0.0872085
-0.0872085
21
-0.0872085
-0.087743
Zone
Cache dz/dy
Mat-level dz/dy (example)
0
0.00359863
0.00360102
1
0.00359863
0.00360102
18
0.00360352
0.00360102
20
0.00360352
0.00360102
21
0.00360352
0.00360102
The differences are not dramatic, but now looking at it, it seems suspicious that the dz/dy does not change at all on mat level. @gtuci@miruizdi are rotations around the x axis done by the alignment in version AlignmentV10_2023_05_09_LHCP?
Hi @gunther! Alignmentv10_2023_05_09_LHCP was aligning only TxTzRz dofs (so translations in x and z and rotations around z) for the modules and TxTz for the mats.
One problem that I can see with having different z for hits of one half is the additional memory needed, since we are already on a budget for shared memory and registers.
Adding the z value for each hit would double the shared memory used and is probably not doable if we want to stay efficient. What we can do instead, is select between two cached z, based on the x of the hit. Would that be sufficient ?
dzdy is not used in the seeding. dxdy and z are currently hardcoded, but could be moved to use the geometry values without performance penality.
that's very difficult to judge without trying. In HLT2 I currently opt for different levels of precision depending on the stage in the algorithm: if the x of a track is known I indeed use a z cached by SciFi quarter for finding more hits, but in fits I now use the properly aligned positions per hit (really per mat), which is costly in computational performance but ensures that we get reasonable physics quality, in the end the trade-off seems worth it. regarding dxdy, if it's not used in fits, we might get away with using the value from the geometry. But it should be checked if there's something to gain by using it on a quarter level or even for each hit (mat) separately.
We should keep in mind that HLT2 throughput is not the most pressing issue at the moment. In HLT1 this might be another story but I let @lohenry comment what the HLT1 seeding actually assumes.
FYI I did a little inventory of the SciFi geometry usage in the seeding and forward tracking in HLT1 and will present it in today's WP2+4 meeting after @gunther 's talk: https://indico.cern.ch/event/1299282/