Bug #1956

Incorrect calibration map lookup in TrackerMCDigitization

Added by Rajaram, Durga almost 4 years ago. Updated almost 4 years ago.

Target version:
Start date:
15 February 2018
Due date:
% Done:


Estimated time:
New Issue


Chris Rogers noted that using non-default mapping & calibration files caused the #TKD_tracks / # TKU_tracks ratio to plummet.

Traced to the digitizer doing an incorrect lookup of the calibration map.

The calibration map contains bank, channel.... which refer to the front-end bank/channel number.
The digitizer does not distinguish between front-end channel numbering and vlsb numbering thus resulting in incorrect channels being looked up for the calibration.


application_tests.log (2.12 KB) application_tests.log Franchini, Paolo, 15 February 2018 17:20

Updated by Rajaram, Durga almost 4 years ago

The effect of this bug is that the wrong calibration gets associated with the hit channel and finds gain, ped = 0 and then sets the #pe to -10.0 which subsequently results in clusters/spacepoints/tracks not being found with these hits.

The bug is:
In MapCppTrackerMCDigitization::compute_adc_counts:

      _SciFiadcGain = _calibration[bank[i]][chan[i]].asDouble();
      _SciFiadcPed = _calibration[bank[i]][chan[i]].asDouble();


is filled by reading the calibration file and bank[] and chan[] are filled by reading the mapping file

But, it fails to note that the vlsb bank number in the mapping file is not the same as the front-end bank number in the calibration file

RealDataDigitization does it correctly calibration map
double adc_pedestal  = _calibration[bank][channel_ro]["adc_pedestal"].asDouble();
double adc_gain      = _calibration[bank][channel_ro]["adc_gain"].asDouble();

and then get the tracker, station, plane, channel corresponding this bank, channel with a lookup of
oldbank = bank%4
board = floor(bank/4)
get_StatPlaneChannel(board, oldbank, channel_ro...) --> sets the tracker, station, plane, channel associated with the unique ID of board, oldbank, channel_ro


Updated by Rajaram, Durga almost 4 years ago

I have fixed this by:
  • create a unique ID for each vlsb board:bank:channel (and thus tracker,station,plane,channel) during mapping file read
  • lookup the unique ID associated with the tracker station plane fibre hit
  • decode the board, bank, channel & the front-end bank, channel associated with this
  • lookup the gain, pedestal using the correctly decode bank channel

In the process cleaned up a bit of unnecessary looping etc


Updated by Rajaram, Durga almost 4 years ago

My proposed fix is on launchpad. lp:~durga/maus/tracker-digitizer

Verified that running against a random G4BL input:

  • with the default map: #TKU/TKD = 429/106
  • with 9970 map: #TKU/TKD = 431/106 (with the bug in the trunk, it was 189/32)

Updated by Rajaram, Durga almost 4 years ago

Unless the tracker group has objections, I'll push the fix to the trunk.


Updated by Hunt, Christopher almost 4 years ago

No complaints from me. Thanks for sorting this Durga.


Updated by Franchini, Paolo almost 4 years ago

Hi Chris,

the integration tests "Run helical sim" is failing in a couple of places as in the attached log. How have the limits (2 in the RMS and 1 in the mean) been defined? Can we change them?


Updated by Hunt, Christopher almost 4 years ago

That is a good question. I don't know for certain, they were part of Adam's test procedures.

I believe he configures a test MC, then just uses the reconstructed parameters as the test criteria, so you are probably fine to change them.

I'll have a look anyway in case there's something a little interesting going on. If you don't hear anything from me by next week, it probably means its fine.


Also available in: Atom PDF