Index
Geometrical description of the SSD module
Detector response simulation
Cluster_finding_and_local_reconstruction
Calibration Files (OCDB)
ECS Run Types and Detector Algorithm
Geometrical description of the SSD module
Each of the 1698 SSD modules (748 on layer5 and 950 on layer6, module index ranging 500-2198) is a double-sided silicon strip detector. Both P- and N-side has 768 strips, strip numbering ranging 0-767. Strip 0 on Pside is opposite to strip 0 on Nside (note that hardware numbering ranges 0-1535, with strip 1535, on Nside, opposite to strip 0 on Pside. This leads to conversions of the type strip=1535-strip for Nside, e.g. in the streamer class for rawdata decoding, see below).
P- and N-stereo angles are 7.5 milliradiant and 27.5 milliradiant, respectively, leading to a P-to-N stereo angle of 35 milliradiant. This small value eventually decreases the resolution (750 microns) along the z-coordinate parallel to the strips but reduces the number of fake intersections (ghosts). The resolution along the x-coordinate, perpendicular to the strips, is down to 20 microns.
Detector size along x (r-phi): 72960 microns
Detector size along z: 40000 microns
Detector thickness (local y): 300 microns
Strip pitch: 95 microns
Stereo angles, detector sizes and number of channels are controlled via the AliITSsegmentationSSD class, which also provides the tools for system frame conversion (local to global and viceversa).
Each SSD module is readout by 12 chips, 6 on P- and 6 on N-side, each of them reading 128 strips. Conversion from local coordinates to chip index is also provided by AliITSsegmentationSSD for dead area recovery during tracking (if the track misses the point, the tracker checks if the area is readout by a dead chip).
Top
Detector response simulation
The SSD response simulation and digitization proceeds via the AliITSsimulationSSD class with the method DigitiseModule(), which in turn is called for each module by the HitsToDigits method of AliITS. Calibration and segmentation information are obtained via the AliITSDetTypeSim class.
DigitiseModule calls:
- HitsToAnalogDigits, which provides the analog strip signal from the energy release of the particle passing through the module. The step between two geant hits (tipically, one entering and one exiting the module for perpendicular tracks) is further divided into 25 microns steps to allow for a better geometrical description of the charge distribution in the silicon. From the energy release in the step a certain amount of charge is produced (as electron-holes pairs generated in the middle of the step) which drifts as gaussian clouds to the two sides of the detector (electrons to the P- and holes to the N-side). The width of the cloud (which eventually determines the number of strips involved by the cloud) depends on the drift constant D and on the drift time, which in turn depends on the drift velocity and the location of the generation point. Both D and drift velocity differ for the two types of carriers. The percentage of the charge gaussian cloud which spatially corresponds to a strip is given to that strip.
- SdigitToDigit, which in turn:
- distributes the signal to the neighbouring strips according to the capacitive coupling,
- adds the electronic noise (modeled as a gaussian distribution) to each strip (noise values are taken from the OCDB via AliITSCalibrationSSD);
- kills dead strips;
- zero-suppresses those strips with signal below 3*sigma_noise.
- signal is finally converted to ADC units and uncalibrated for the gain (with values from the OCDB).
Top
Cluster finding and local reconstruction
Cluster finding and local reconstruction in the SSD proceeds via the AliITSClusterFinderV2SSD class. As AliReconstruction::RunLocalEventReconstruction calls AliITSReconstructor::Reconstruct for the ITS and in turn AliITSDetTypeRec::DigitsToRecPoints, two different methods of AliITSClusterFinderV2SSD (FindRawClusters or RawdataToClusters) are called depending whether the input is a digits file (essentially from simulation) or a raw data file (from real data). The two methods perform one-side clustering on both P- and N-side of the module. This is done searching for neighboring activated strips and grouping them together into Ali1Dclusters objects. In both cases (from digits or from read data) the method FindClustersSSD of AliITSClusterFinderV2SSD is finally called to match P- and N-side 1Dclusters and produce recpoints. Charge matching (requiring the ratio between the charges of P- and N-side 1Dclusters to be close to unity) can be switched on/off at run time via the AliITSRecoParam class.
Cluster finding from rawdata (the RawdataToClusters methods mentioned above) requires a preliminary buffering of the rawdata at the level of the AD-module in the front-end electronics. An AD-module contains 12 ADCs, each of them reading the signal of the 1536 strips of one module. Due to efficiency motivation, each AD-module reads the ADCs in parallel, eventually leading to a pattern like mod1/strip1, mod2/strip1, mod12/strip1, mod1/strip2, ... in the raw stream. Neighboring strips are therefore messed up between 12 modules: buffering and indexing the data for groups of 12 modules is then needed before clustering.
Before clustering, the signal from each strip is calibrated for the gain (with values from the OCDB) and converted from ADC units to KeV via AliITSCalibrationSSD. Suspiciously big clusters are split into smaller ones (this feature can be switched off at run time via the AliITSRecoParam class).
The actual cluster finder (FindClusterSSD) which matches P- and N-side 1Dclusters to produce a reconstructed point, works on a quality basis:
- all the “gold” crosses (involving only one 1Dcluster on each side) are used. The recpoints from gold crosses are assigned a “quality” factor of 1 (or 2 in case the total amount of strips involved in the two 1Dclusters exceeds 6);
- then, all the “silver” combinations (2 P-side 1Dclusters crossing 1 N-side 1Dcluster or viceversa) are used. A quality factor of 5 (or 6) is assigned to the two recpoints;
- the 2xmany combinations, origin of ambiguities (ghosts) can be disentangled using charge matching. A 2x2 combination, for example, which gives 4 crosses, will eventually produce 2 recpoints (the two ghosts being rejected by the charge matching requirement). Recpoints are given a quality factor of 10 (or 11);
- all the remaining combinations are taken into account. No charge matching is required (only crosses). A quality factor greater than 100 (100+number of 1Dclusters involved) is given.
Top
Calibration Files (OCDB)
There are 4 directories in ITS/Calib with calibration data to be used in SSD reconstruction
1. NoiseSSD
The OCDB file contains a TObjArray of AliITSNoiseSSD objects, one for each of the 1698 modules. Each AliITSNoiseSSD object contains two TArrayF, 768 in size, with the noise values for the 1536 strips (768 on P-side and 768 on N-side). The noise values are calculated by the detector algorithm during a special calibration run (pedestal run, see below) and transfered to the OCDB via FXS and SHUTTLE. Noise values from the OCDB are used in the simulation via the AliITSCalibrationSSD class to simulate the noise and to zero-suppress the data. They are also used in reconstruction to reject 1Dclusters due to the residual noise after zero-suppression.
2. PedestalSSD
The OCDB file contains a TObjArray of AliITSPedestalSSD objects, one for each of the 1698 modules. Like NoiseSSD, two TArrayF of 768 floating values contains the pedestal values for the 1536 strip of the module. Unlike noise, pedestal are saved as reference data only.
3. BadChannelsSSD
The OCDB file contains a TObjArray of AliITSBadChannelsSSD objects, one for each of the 1698 modules. Two TArrayI (one for each of the 768 strip on each side) contains a mask indicating whether the strip is good (0 in the less significant bit) or bad (1 in the LSB). Other bits are used to specify the nature of the bad behaviour. Bad channels are used both in the electronics to mask bad strips and in the reconstruction to recover them.
4. GainSSD
Gain are used in reconstruction. For the time being, static values are saved in the OCDB.
Top
ECS Run Types and Detector Algorithm
- STANDALONE RUNS are intended for test purposes. No DA is launched after EOR.
- PEDESTAL RUN
- PHYSICS RUN: nothing has to be done on the DAQ machines.
Top
