Page contents

This is a page to help me (and maybe others) to define the structure and workings of MarlinTPC.

Basic structure: FADC based reconstruction

The main parts of MarlinTPC reconstruction can be divided in

  1. (hardware) channel based reconstruction
  2. row based reconstruction
  3. track reconstruction

Note that the first step here is only for FADC / pad based readout structures. The second step eventually applies only for row based reconstruction, although a similar outcome may exist for non-row based reconstruction.

Input definition

The assumption is a DAQ system that runs on a number of channels, which are connected to pads that are located somewhere in 3D space. The charge signal on the individual pads is quantized in its amplitude in ADC values and sampled with a certain frequency, which defines a binning in time. The zero point in time is defined from an outside trigger.

From the real world comes the information of a (hardware) channel id together with a starting time bin number (zero for non-zero suppressed data or the first bin above the zero-suppression threshold). For this specific channel at this specific starting time a vector of adc values is stored.

Input Data type

The corresponding data type is LCIO::TRACKERRAWDATA The accessors for CellID0 and CellID1 identify a certain channel number, ID1 is the number of the module, ID0 the hardware channel number on this module.

CAVEAT: if you want to write/store the module ID, you have to add a specific line to activate it.:

// set the flags that cellID1 should be stored
        lcio::LCFlagImpl trkFlag(0);

Channel based reconstruction (FADC only)

These reconstruction steps work only with the information of a single hardware channel. They can be further divided into the action upon single adc values and the first abstraction of combining several adc values of a single channel into a pulse.

Reconstruction with single adc values

Tasks that arise for the raw values from the electronics:

Data type after electronics processing


Structurally this data type is not much different from TrackerRawData, but conceptually the electronics information is processed. The hardware ID is the same as before. The adc values and the time are now (possibly corrected) floating point numbers.

CAVEAT: The time is still in (possibly fractional) units of the time bins of the electronics. Conceptually this is not a clear separation.

Pulse reconstruction: combination of several adc values in a single hardware channel

The next step is to join several adc values into a higher level abstraction, a pulse. The task is therefore to do pulse finding, which comprises several conceptually related steps:

Furthermore the conversion tasks need to be done:

Pulse Data Type


Again the hardware channel IDs are used, since the information is still based on individual channels. The time is given in ns. The charge is given in adc values. (CAVEAT: agreement to give it in number of primary electrons?) The quality integer is in fact a bit pattern:




multiple pulse candidate


pulse comes from splitting a pulse


anomalous shape






unused for now


private usage


force spectrum storage

To set/read a specific bit 'n' use the bitwise shift operator, and compare with the bitwise and or the bitwise assignment:

TrackerPulseImpl aPulse;
if( aPulse.getQuality() & ( 1 << n) {...}

// writing
int quality = 0;
quality |= ( 1 << n);

Higher Reconstruction (Row based)

Row based reconstruction: Hits

Track reconstruction

Track seeding and finding

Track fitting

Unsorted list of tasks


input -> output


flag broken channels

TrackerData -> TrackerData

conditions data

flag overflow channels

TrackerData -> TrackerData

conditions data

correct raw adc values

TrackerData -> TrackerData

conditions data

convert bin number to time

TrackerData -> TrackerData

conditions data

correct raw time info

TrackerData -> TrackerData

conditions data

convert adc count to charge

TrackerData -> TrackerData ?

conditions data

convert time info to z

TrackerPulse -> TrackerPulse ?

conditions data

correct z info

TrackerPulse -> TrackerPulse ?

conditions data

pulse finding

TrackerData -> TrackerPulse

reco processor

pulse splitting

TrackerData -> TrackerPulse ?

reco processor

pulse flagging

TrackerData -> TrackerPulse

reco processor

channel mapping

TrackerPulse -> TrackerPulse

conditions data

hit finding

TrackerPulse -> TrackerHit

reco processor

hit flagging

TrackerPulse -> TrackerHit

reco processor

calculate covariance matrix

TrackerPulse -> TrackerHit

reco processor

apply xyz correction

TrackerHit -> TrackerHit

conditions data/reco processor ?

static conditions data (fixed for one event and/or run):

dynamic conditions data (requires processing):


MarlinTPCStructure (last edited 2012-01-26 16:08:33 by RalfDiener)