Skip to content

InDet candidate alg. Extrapolate tracks only to sectors containing a hit

Johannes Junggeburth requested to merge jojungge/athena:MuonInDetPerf_Run3 into master

Hi,

this MR tries to mitigate the large CPU consumption of the MuonInDetCandidateAlg in the run 3 geometry

image

I noticed that the MuonSystemExtensionTool extrapolates the ID tracks through the MS without checking whether the sector actually has a hit from any muon chamber. If not the track is extrapolated in vain through the MS without have ever a chance to form a combined track. This MR adds the following features to the MuonInDetCandidateAlg

  • Usage of the PrepRawData containers of each muon system to spot the sectors with potential hits. The search is performed separately for EndcapA, EndcapC, and the Barrel region.
  • Introduce the UseOnlyHittedSectors property to the MuonInDetCandidateAlg to optionally switch on this new feature
  • Simplify the signature of the IMuonSystemExtensionTool by piping a cache object containing the InDetCandidate, the hit sectors and the switch whether the extrapolation shall only be restricted to those sectors
  • Cache the Trk::CaloExtension in the InDetCandidate as I remember there are several places in the code downstream where this is needed

I already performed a CPU benchmark on the SPOT file demonstrating the reduction of the CPU footprint by a factor of 6.

  • Old v-tune

image

  • New v-tune

image

A large scale test of this MR is going to be submitted in parallel

Despite, the big improvements in CPU consumption, there still remains the question of why the extrapolation in the Run 3 geometry takes soo much more time than in the Run 2. Could this be related to some weird features in the TrackingGeometry?

Tagging: @christos, @sroe, @emoyse, @goblirsc, @wleight Relates to ATLASMCP-107

Edited by Johannes Junggeburth

Merge request reports