Radiation Damage Digitizer code (SensorSimPlanarTool) speedup

Closed Kevin Sedlaczek requested to merge (removed):QT_Speedup_Digitizer into 21.3

This request contains several changes that form the final result of last years QT project related to making the Pixel radiation damage digitization code faster (ATLPHYSVAL-654). The final code is about 3 times faster than the current code or about 2 times slower than not including radiation damage at all (setup for deriving these numbers defined in the slides listed below). Changes are mostly of technical nature. These results were presented in several meetings in the last weeks:

ATLAS Simulation (half-time presentation: https://indico.cern.ch/event/848665/contributions/3585831/attachments/1934868/3206109/qt_sedlaczek_kevin.pdf)

ATLAS Simulation (final presentation: https://indico.cern.ch/event/886041/) Pixel general meeting (final report: https://indico.cern.ch/event/917863/contributions/3857618/attachments/2036143/3409193/qt_sedlaczek_kevin.pdf)

Radiation Damage meeting (last Update: https://indico.cern.ch/event/911356/contributions/3837742/attachments/2025436/3388088/RadiationDamageUpdate.pdf)

The changes are the following and can be grouped into two categories and are all motivated by saving CPU time:

  1. Technical Optimization:
  • Replace GetXaxis->FindBin calls inside the inner loop of the radiation code by arithmetic, because the called histograms are constant input from pre-defined maps and only consist of equally sized bins. For this I added three maps that contain these multiplication factors (basically just #bins * (x - X_min) / (X_max - X_min)) in SensorSimPlanarTool.h and changed the FindBin calls to that multiplication.

(The following changes were suggested by Tommaso Lari):

  • Remove test variables and calculations no longer needed (ramo_i_e and other ramo*_i* variables)
  • the z dimension of the calls of FindBin is unnecessarily located within the nn-loop and therefore evaluated too many times → move before loop
  • when the hole has reached the backend, ramo_h is set to zero for all iterations in nn-loop → add if condition and perform necessary calculations only if not the case.
  • do the same for electrons and one can also skip the reading of the map for the final electron position when it’s true
  1. Cutting away some not too relevant cases:
  • In order to reduce the large number of iterations in the inner most loop (over the nearest neighboring pixels (p,q) for every charge) we reduced the limits for the iterators. The edge cases (p==+-2 || q==+-2) make 2/3 of the neighbors and do not change the results significantly. We studied different high level variables to validate the small impact. This is done without any additional computational overhead by directly changing the calculation of the limits to be inside +-1.

Merge request reports