TRT FastOR Algorithm implementation in Athena

The code is been validates using the Athena release 17.2.5.2, which is currently available on the SLC5 machines on lxplus. To get the code, please make a working directory and setup the Athena release mentioned above:

• mkdir FastORAlg
• cd FastORAlg
• asetup 17.2.5.2,here
• cmt co -r TRT_Digitization-00-10-74-11 InnerDetector/InDetDigitization/TRT_Digitization
• cmt co -r TRT_PAI_Process-00-00-38 InnerDetector/InDetSimUtils/TRT_PAI_Process
• cd InnerDetector/InDetDigitization/TRT_Digitization/cmt
• cmt bro "cmt config; gmake"

Basic structure of the code

The manin modificantions to the digitization code, were made in the following classes:

• TRTElectronicsProcessing :
  • This class has a function called “ProcessDeposits” in which most of the relevant methods in the processing of the straw information are called (take place), such as the signal shaping, adding the electronic noise, discrimination (conversion of the energy deposits in the straw to binary format) and encoding of the LT and HT info into a number.
  • The “ProcessDeposits” function is called by other different classes in the digitization code. For this reason, thi function was modified to pass a vector with the HT information of a straw after the discrimination step.
  • The vector is only filled if there is at least 1 HT bit high in the straw, which helps greatly with the CPU processing time.
• TRTNoise:
  • –This class had a minor modification. Since the “ProcessDeposits” is called here, the function needed to be modified to include the new vector.
• TRTProcessingOfStraw:
  • This class has a function called “ProcessStraw” which is called by the “TRTDigitizationTool” class where the loop over all the straws, in a straw by straw basis, takes place.
  • The “ProcessDeposits” function is called in the “ProcessStraw” function for which it needed to be modified.
  • Similarly, as done on the “ProcessDeposits” function, a vector storing the HT information after the discrimination step was added to the arguments of the “ProcessStraw” function and subsequently passed to the “ProcessDeposits” to be filled.
• TRTDigitizationTool:
  • The most significant modifications made in the existing code, happened in this class, specially in the “ProcessStraws” function.
  • As mentioned before, the “ProcessStraw” function is called in this class, in the “ProcessStraws” function. So the “ProcessStraw” function was modified to add the new HT vector.
  • Four new vectors were defined in the code:
    1. m_fastOR_Htvector : is a vector of vectors that stores the HT information of all the straws with at least 1 HT bit high (m_highThresholdDiscriminator).
    2. m_fastOR_chipId: stores the chip information associated with each straw.
    3. m_fastOR_phiId: stores the φ stack position information.
    4. m_fastOR_barrelEC: stores the information of the side of the detector (A or C).
    5. The code necessary to fill the vectors was also implemented in the “ProcessStraws” function.
  • The figure below, shows the FE board layout for the detector.
  • The mapping was of the straws to DTMROCs, in the barrel, was done shifting the chips IDs on the barrel in order to obtain a consecutive numbering from 0 to 103. This is very useful since in the original format the IDs on the barrel are repeated for each layer. In this way, we do not have to pass the Layer ID information to the “TRTFastORAlg” class.
  • The mapping for the ECs is easy as all the wheels have 12 chips per FEB.
  • All the code implemented for the FastOR, while looping over the straws, is only used for those straws which have at least 1 HT bit high. This condition is applied by requiring the HT vector for the straw not to be empty.
  • After done looping over the straws, the main function for the FastOR algorithm class is called if the “m_fastOR_Htvector” is not empty. If this vector is not empty, then the function is called and the five vectors it takes as input are cleared.

TRTFastOR Class

• The current implementation of the “TRTFastORAlg” class has the following functions:
  1. TRTFastORAlg _getStrawId: this function is the main function, where most of the processing of the information takes place. This function takes as input the four vectors described before. In this function, two 4D arrays and two3D arrays are defined:
     1. m_preprocessing_straw_HT_ternaryInfo[side][phi][chip][bin] --> used for preprocessing. This array stores the HT bits information in 24 bins, each equivalent to 3.125 ns “time”.
     2. m_preprocessing_Nchips_per3125[side][phi][feb][bin] --> used for preprocessing. This array stores the number of chips with HT bits high (3.125 ns “time”) per FE board.
     3. Chippos[side][phi][chip]. This array is set 1 if the straw has at least 2 HT bits high. This condition is only used for testing purposes.
     4. FEboard[side][phi][feb]. This array stores the number of chips per FE board that have HT hits.
     • A one dimensional array of 29 elements (29 FE boards per φ stack), called “phiStack”, is used to store the resulting information from the “FEboard” array (number of chips with HT hits for an specific side, φ stack and FE board).
     • An initial version of the signal preprocessing is also available.
       • The information from the HT vector for each straw (160 bins, each corresponding to 0.78125 ns) is stored in the “m_preprocessing_straw_HT_ternaryInfo” array using 24 bins.
       • The number of chips per FE board per “time” bin with HT-bits high is counted and the information is stores in the “m_preprocessing_Nchips_per3125” array.
       • A simple condition is then applied in order to execute the next part of the FastOR algorithm: the number of gaps per FE board (Ngaps) (bins with not HT bits high) in the “m_preprocessing_Nchips_per3125” is counted, starting from 6.5 n, and the next part of the algorithm is only applied if the Ngaps is less than 6.
       • The aim of this part was to leave ready the basic machinery for the preprocessing.
  2. There is an standalone file called “TRTFastOR.Patterns” with the definition of the arrays that contain the valid HIP patterns needed for the algorithm.
     • This file can be found in the “TRT_Digitization” directory.
     • The file is passed to the “TRTFastORAlg” class as an include in the source file at the beginning of the code: #include "TRT_Digitization/TRTFastOR.Patterns”.
     • The figure below shows the current content of the “TRTFastOR.Patterns” file.
     • 
  3. TrigPass: This function perform the following tasks:
     • Counts the number of FE boards that are expected to be active for a specific pattern, e.g. const int Bar_trigConf_0[29] = { 0, 1, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
     • For the boards in the pattern that must be active (red numbers in the example above), compares the number of active chips (chips with HT hits) from the “phiStack” array to the expected number of chips expected for that pattern, e.g. const int Bar_trigPat_0[29] = { 0, 6, 8, 0, 0, 0, 0, 7, 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
     • If the event has the required number of active boards and active chips per board, the function returns “1”, otherwise “0”.
  4. The “TrigPass_ec” has a very similar structure as the “TrigPass” function. The main difference is that the number of chips required to be active for each FE board is the same, so the arrays “e.g. Bar_trigPat_0” are not needed. Instead the “TrigPass_ec” takes as input in integer number with the desired number of chips (currently set to 2 as a dummy value).

Output

• For each event, the code returns an integer encoding the information from the detector side, the Ï• stack and the trigger decision.
• The encoding of the information is done in the following way.
• The result from the trigger per each φ stack is placed in a 64 bit long data word.
• The first 32 bits, correspond to the side A of the detector, each bit representing a φ stack. The remaining bits, correspond to the side C of the detector.
• The encoding of the information if done in the following way: Output = TrigDec[side][phi]*pow(2,p)
• In the equation above, p correspond to the position of the bit in the 64 bit word.