TGC Digitization: Implementation of signal propagation time between the sensor edge and ASD
Add the new db system to fix the missing timing calculation at the TGC_Digitization stage between the sensor edge and the ASD. TGC_Digitization retrive the information of the distance between the sensor edge and ASD from the condition db. Condition algorithm (TGCDigitASDposDbAlg) and condition object (TGCDigitASDposData) have been added to manage the condition data in AthenaMT. TGC_Digitization has been modified to use the new TGCDigitASDposDbAlg and TGCDigitASDposData and added the method to calculate of signal propagation time from sensor edge to the ASD. The compilation is fine, no errors or warnings. The test has been done locally.
This MR will be done in parallel with !46507 (closed).
Merge request reports
Activity
122 117 addET(et, cell); 123 118 124 119 m_scID[cell] = ID; 125 120 126 121 //multi linear digitisation encoding 127 unsigned int ecode = eFEXCompression::Compress(m_et_float[cell]); 128 int outET = eFEXCompression::Expand(ecode); 129 130 //noise cut 131 const bool SCpass = noiseCut(outET,layer); 132 if (SCpass){ m_et[cell] = outET;} 133 else{ m_et[cell] = 0; } 134 122 unsigned int outET = eFEXCompression::decode((unsigned int)m_et_float[cell],layer); @watsona - I was trying to understand the simulation SW and these casts of the m_et_float to unsigned int looked very worrying to me, at the very least because can't et_float values be negative in some cases, no? There's several of these lines throughout the eTower code ...
I've been trying to understand some of this stuff myself as part of planning for filling these things from eFexTowers. But this should not be cast to unsigned int: the eFEXCompression function used here accepts a signed int as input, and this is for a reason (LAr ET values can be negative).
As long as the casting doesn't convert to a 2s-complement unsigned it's harmless here, because we're going to set the negative values to zero anyway. But I have a horrible feeling that could be a platform-dependent behaviour.
I would dearly like to get rid of the floats completely, but the problem is that they serve a purpose when dealing with the "split" layer 1 cells between 1.8-2.0 (but nowhere else). But this whole compression business is something I intend to remove from eTower when I have the time to do it and do all of the validation, because (a) it's all linked in with the noise cuts, and I want to move them out of this object so we can set values from COOL, and (b) the eTower object is currently constructed only for inputs from supercells (ET in 1 MeV granularity signed floats) and I do not want to convert eFexTower ET values to floats and then put them into these things to be recompressed and decompressed again, that's just too stupid for words ;).