Cathode Strip Chambers

Offline Analysis Tools


This page describes offline handling of data recorded from the CSC (cathode strip chambers). The chambers cover the forward and backward eta regions from 2.0 to 2.7 and serve as the first muon station over that eta range. This station provides four measurements in both eta and phi. The eta strips are relatively narrow ( 5.5566 mm for the Small Chambers, 5.308 mm for the Large) and charge sharing between adjacent strips can be used to measure positions with a precision of better than 100 microns. The phi strips are wider (12.922 mm for the Small chambers, and 21.004 mm for the Large) and signals are typically induced on only two strips yielding measurements with worst resolution or, if high precision is assumed, long residual tails.

The default reconstruction includes steps to construct each of the following in turn: digits, 1D clusters, 2D segments (i.e. one position and one direction), and 4D segments. Different track finding and fitting algorithms may use any of these elements; most typical at present is to use the clusters.

A description of the CSC Monte Carlo is also given.

Detector Characteristics

Momentum resolution

The CSC radial (eta) position measurement is essential to the muon spectrometer momentum measurement in the region |eta|>2.0. MDT's following the forward toroid can be used to predict the CSC position for a straight track and the deviation x from that prediction provides a measurement of the momentum. The toroid provides a field integral of approximately 6 T-m over a path of 4 m. The relation between the position deviation and momentum is approximately

  x = H 1/p

where H = 3.6 TeV-mm. E.g. a p = 3.6 TeV muon (pT = 1.0-0.5 TeV for eta = 2.0-2.7) will deviate by 1.0 mm from a straight trajectory. Thus, if we want 10% resolution for such muons (0.027 /TeV in 1/p) for such muons we must keep the combined position resolution and misalignment under 100 um.

Timing resolution

The CSC timing measurement is another important one especially for EF trigger and beam halo events veto. The time measurement is relative to the start of the readout window, i.e., sample 0. This time is determined by the latency setting which is adjusted so that times peak in the middle of the window. We have 4 samples at 50ns, covering 150ns, so the center is at 75ns. This is our T0 which will be subtracted.

Still, if the first sample is the largest and the interpolation indicates peaking before the first sample, then the time is set to 0 as a flag and as an aproximation. Same for the peaking times after the last sample.

If the trigger comes between two 50ns samples, then we subtract 25 ns from the measured time because our window is shifted relative to the trigger by that amount. This is called trigger phase = 1. Unfortunatly the flag values of 0 and 150 are also shifted. As a result, we have valid times starting from -25 ns for phase 1, but the flag of phase 0 is still at 0ns.

Parabola interpolation of ADC samples followed by bipolar correction provides a time measurement of each channel (strip). For the cluster, we consider the measured time of peak charge strip as a time of cluster. Each 2d segment (eta/phi) has 3 or 4 hits (clusters) associated. The unweighted average of the 3 or 4 cluster times can be used as a time of segment.

To use the time measurement correctly, t0 values should be subtracted. T0 is the average peaking time for segments from the IP. It is the sum of the T0 base value of the channel and 12.5ns times the T0 phase of the readout fiber of the channel. The T0 base value depends on the shaping time of the analog electronics and is expected to be constant over time. The T0 phase, however, can change from one run to the next. It takes on the possible values of 0 or 1 and shifts the times by 0 or 12.5 ns. In one chamber, there are 5 T0 phases to be calibrated: 4 precision layers (eta) and 1 non-precision layer (phi). Note that the 4 precision layers are however split in the middle and combined. This gives us ch1-92 for layers 1(2) and 3(4) in one constant, ch93-192 of layers 1(2) and 3(4) in the next, etc. These t0 constants needs to be saved in COOL db.

Geometry and readout

The CSC detector consists of 32 chambers, 16 on each endcap. The 16 are arranged in eight phi-sectors on each of two wheels with an azimuthal overlap to provide hermetic coverage in phi. The two wheels are named CSS (*Small Chambers) and CSL (*Large chambers) following the overall ATLAS geometry of and a chamber is identified by specifying the wheel, eta side (- or +) and phi sector (1-8). There are four planes of wires within each chamber with orthogonal strips on the two cathode planes providing measurements in the eta and phi directions. Thus a readout plane may be identified by the wire plane number (1-4) an orientation (eta, phi). Strips are numbered consecutively starting from one in each plane. There are 192 strips in the eta planes and 48 in the phi planes.

The eta strips are relatively narrow (5~6mm) so that the signal induced by a single charged particle typical registers on three or more strips making it possible to distinguish isolated tracks from those overlapped by other tracks. The latter are called spoiled. In the former, unspoiled, cases (80-90% of the tracks) it is possible to use distribution of charges on adjacent strips to determine the track position to high precision, better than 100 microns. The phi-measuring strips are much wider (1~2cm) and the signal from a single track is generally confined to one or two strips, making this precision measurement less significant. The spoiled eta and most or all of the phi measurements have a resolution of a few mm. For this reason, the eta coordinate is called the precision coordinate.

The readout for each strip includes ADC sampling at regular intervals. Typically four samples are read out. The time distribution is used to determine the time at which the particle interacted with the detector. The shape of the signal may also be used to determine whether there are contributions from multiple particles at different times.

Data structures

The following describes the data structures


Hits, class name CSCSimHit, record the simulated (GEANT) interaction of a particle with the CSC detector. They hold the identity of the particle, the starting and end positions of the GEANT step, the mean time and the energy deposited in that step.


Three separate classes are used to describe the response of a single strip: the original digit class CscDigit, the prep data digit CsctripPrepData, and the RDO description CscRawData. The original digit class holds the total charge and time and is presently used only to hold the output from the first stage of digitization. Apparently the time is always left zero. The RDO description is obtained either by running the second step of digitization or by conversion from bytestream, the format of the data read from the detector. The prep data digit is an unpacked and calibrated form of this data. Both RDO and prep data descriptions include the charge for each time sample. Although the latter are prep data objects and hence can be used as input for track reconstruction, the nature of the detector suggests it is preferable to first cluster the strips.

All digit containers hold a separate collection of digits for each chamber. The time samples for each strip are combined to a single measurement of charge and time, the "strip fit".


A cluster is intended to provide a measurement of the coordinate where a charged particle crossed a wire plane. Existing algorithms construct 1D clusters which use information from one cathode plane to provide a single coordinate (i.e. that associated with the plane). In principle it is also possible to construct 2D clusters with include information from both planes and thus provide measurements of both coordinates but this is not currently done. We often drop the qualification when referencing 1D clusters.

Clusters are stored as prep data objects of type "CscPrepData". Each cluster holds identifiers for the digits from which it was constructed and a fit of the measured coordinate. The measurement is expressed as a 1D vector with a 1D error matrix with a surface specifying the orientation.


A CSC segment provides a measurement of position and direction within a chamber and is formed by combining one cluster from each of the planes in that chamber. Both 2D and 4D segments are supported: the former measure the position and direction for one orientation (eta or phi) and the latter provide a complete measurement of both coordinates and directions at a specified plane, typically at the center of the chamber.

The class describing CSC segments is the common muon segment class: MuonSegment. It holds the list of contributing prep data objects, typically clusters and fit, i.e. the above measurements and their error matrix. The ordering is the same as that for the clusters.

The muon segments for a chamber are stored in a collection of type MuonSegmentCombination and these are held in the collection of type MuonSegmentCombinationCollection. The muon segment combination is a collection of vectors of muon segments. For 4D segments, a single vector is used and, for 2D segments, the phi and eta segments are written to separate vectors if the algorithm looks for both. All is by convention or choice of the algorithm author. There is nothing in the classes to require or even encourage this organization. Unlike the digits and clusters, the current algorithms do not write empty containers (muon segment combinations) when no segments are found in a chamber. Instead one MuonSegmentCombination is written for each chamber that has one or more segments. If no segments are found in any chamber, then an empty MuonSegmentCombinationCollection should be written to affirm that the algorithm has been run.

Tools and helpers

A number of tools (AlgTools) and helper classes are available for working with CSC data objects.


The CscIdHelper and CscReadoutElement may be used to access geometry information including the identifier hierarchy and position and orientations of various elements.


The AlgTool CscCalibTool may be used performs calibration operations such as transforming back and forth between charge and ADC counts. The calibration constants are retrieved from cool using CscCoolStrSvc, as defined in CscCoolAccess

Pedestal Subtraction

Pedestal subtraction is done during the process of conversion from RDO to CscStripPrepData.

Charge Measurement Error for each channel

When time and charge are extracted for each channel, default error is considered as (F001-Pedestal)/3.251. Alternatively, RMS or Sigma can be used.

Strip Status Bit

It tells if channel is identified as noisy or dead or hot or stuckbit

Electronics Gain Constant (dummy constants)

ADC is calibrated by electronics gain constant ("pslope"). At this moment, we are using default value for all channel.

T0base and T0phase (in progress)

To get a calibrated time measurement, (T0base+12.5*T0phase ) should be subtracted from raw time measurement.

Strip Fitting

AlgTools providing the interface ICscStripFitter may be used to fit a strip (digit) and extract the peak charge and time. There is one implementation, CalibCscStripFitter that makes use of the parabolic fit in the CscCalibTool and adds code to assign errors and handle fit failures.

Cluster fitting

AlgTools providing the interface ICscClusterFitter may be used to fit a cluster to obtain the cluster position and error. There are two implementations: SimpleCscClusterFitter which simply uses the physical extent of the strips with a correction for the intrinsic cluster width and QratCscClusterFitter which does charge interpolation using adjacent charge ratios.

The simple cluster fitter assigns the position at the center of the cluster (no charge weighting) and assigns the error using the RMS of the effective width, i.e. this width divided by the square root of 12. The effective width is the full width (# strips times the pitch) minus the intrinsic signal width which is taken to be constant and provided as a job option.

The QRAT cluster fitter uses the ratio of charge in each adjacent channel to the peak charge to estimate the cluster position using an atanh fumction. If these estimates are consistent, they are combined to obtain the final position estimate and error. If they are inconsistent or any other problem is seen with the charge distribution, then the fit fails and the cluster is flagged as spoiled.



The first step in simulation is event generation. The interaction of two protons are simulated producing a list of particles. Generation instructions can be found at https://twiki.cern.ch/twiki/bin/viewauth/Atlas/WorkBookGeneration and https://twiki.cern.ch/twiki/bin/viewauth/AtlasProtected/RunningGenerators .


The final state particles from the generator and their secondaries are propagated through the detector using GEANT. See AtlasG4Simulation. Interactions with sensitive volume are recorded as hits. For running locally the propagation use the command:

AtlasG4_trf.py inputEvgenFile=input.pool.root geometryVersion=ATLAS-GEO-20-00-01 physicsList=QGSP_BERT conditionsTag=OFLCOND-SDR-BS7T-05-07 maxEvents=-1 skipEvents=0 outputHitsFile=output.pool.root 


The first detector-specific stage of simulation is digitization. See the CscDigitization page for a description of the current status and plans.

Run the atlas digitization using the "transformation" job options:

Digi_trf.py inputHitsFile=./HITS.pool.root outputRDOFile=RDO.pool.root maxEvents=-1 geometryVersion=ATLAS-GEO-20-00-01 conditionsTag=OFLCOND-MC12-SDR-06

Run only the CSC digitization by checking out the package:

cmt co MuonSpectrometer/MuonDigitization/CSC_Digitization

Add in the "share" directory the script:

svn co svn+ssh://svn.cern.ch/reps/atlasusr/kalliopi/CSC_scripts/MasterRunDigitization.py

Run jobs using the script:

svn co svn+ssh://svn.cern.ch/reps/atlasusr/kalliopi/CSC_scripts/RunDigitizationJobs.py



Detector coming off the data is in bytestream format and is unpacked into raw data objects (RDO) using the same CscRdoContByteStreamCnv converter used to create simulated bytestream. Simulation data is typically stored in RDO format. Prep data digits describing the strips are constructed from the raw data objects using the CscRdoToCscPrepData algorithm. This step may be triggered with the following job options.

theApp.Dlls += ["MuonRdoToPrepData"]
include ("MuonRdoToPrepData/CscRdoToCscPrepData_jobOptions.py")


Initial clustering is performed with the CscThresholdClusterBuilder algorithm. Input are prep data digits and output are (also prep data) clusters.

A cluster is formed from all adjacent strips with charge above a threshold (current default is 20k electrons). For eta clusters, if the peak strip, i.e. the one with the greatest charge, is adjacent to a channel below threshold, then the latter is added to the cluster to enable the charge ratio calculation. This should cause clusters to merge when they are separated by a single strip below threshold and either has its peak strip at the edge nearest the other cluster. A splitting algorithm is run on selected eta clusters.

The clustering algorithm may be run with the following job options:


By default, clusters are written to a container named cscClusters.

The clusters are fit using the QratCscClusterFittingTool which provides a precise estimate (typically better than 100 micron) of the track position for unspoiled clusters. If that fitter or the finder itself detrmines that the cluster is spoiled, then the fit is done using the SimpleCscClusterFitting tool for which the error is calculated from the effective width of the cluster. Both are described in the section of fitting tools above.

Segment building

The building of 2D segments is accomplished with the Csc2dSegmentMaker algorithm. Input are clusters and output are 2D segments. It separately finds eta and phi segments within each chamber requiring a cluster from each of the four cathode planes. The following job options are used to run this segment maker:


By default the segments are written to a container named csc2dSegments.

The building of 4D segments is done with the Csc4dSegmentMaker algorithm. Input are 2D segments and output are 4D segments. There is a simple pairing of all combinations of all eta and phi segments within each chamber. The following job options are used to trigger this segment maker:


By default, the 4D segments are written to a container named csc4dSegments.


How to get MuonSegment

In ESD, CscSegments are a part of "MooreSegments". So, this key should be used in storegate as below.

const Trk::SegmentCollection* segmentCollection = 0;
StatusCode sc = evtStore()->retrieve(segmentCollection, "MooreSegments");

First, MuonSegment should be taken out of Trk::Segment by dynamic cast inside of loop:

Trk::SegmentCollection::const_iterator s;
int nSegments = segmentCollection->end() - segmentCollection->begin(); // 
if ( nSegments < 1 ) return sc;

for ( s = segmentCollection->begin(); s != segmentCollection->end(); ++s) {
       Muon::MuonSegment* mSeg               = dynamic_cast<Muon::MuonSegment*> (*s);

To get a chamber name among MDT and CSC, you need to subscribe a tool as:

ToolHandle          p_muonEDMHelperTool;

Then, you can get a identifier out of it as:

Identifier id=p_muonEDMHelperTool->chamberId(mSeg);

Detailed can be found here as well as how to match it with track.

For trigger chamber, one can use Robert's function.


Cluster and segments are validated both by examining their contents and by comparing these contents with truth information in Monte Carlo samples. The latter is a bit cumbersome because it requires accessing the hits files to obtain the predictions, accessing the RDO data to obtain the the measurements and then a comparison of the two. Validation packages extract ntuples summarizing truth or reconstructed data. Performance packages compare reconstructed and truth ntuples.

All validation software is in the MuonSpectrometer/MuonValidation/MuonCscValidation area. Common utilities and macros are in the package CscValidationUtil. For convenience, users will often check out the package used to create and examine the ntuple of interest. It may also be be desirable to check out and build this or other packages to get the most recent version, e.g. (in an ATLAS development area). For cluster validation, you want to check out CscHitValidation (you don't need this if you have csc_simpos.root file), CscClusterValidation and CscClusterPerformance. For segment validation, you want to check out CscHitValidation (you don't need this if you have csc_simpos.root file), CscSegmentValidation and CscSegmentPerformance. For cluster monitoring, you need to check out CscHitValidation (you don't need this if you have csc_simpos.root file), CscClusterValidation. (XXXX is one of CscHitValidation, CscClusterValidation, CscSegmentValidation, CscClusterPerformance, and CscSegmentPerformance)

Validation under 17.2.X

cmt co MuonSpectrometer/MuonValidation/MuonCscValidation/CscClusterValidation
cd MuonSpectrometer/MuonValidation/MuonCscValidation/CscClusterValidation/cmt

Produce validation ntuples using the "test6.py" script:

In case you need the L1ID in the ntuples take the package from :

svn co svn+ssh://svn.cern.ch/reps/atlasusr/kalliopi/CscClusterValidation

Monte Carlo predictions

Monte Carlo predictions are obtained looping over the hits in the CSC volumes. For clusters, an extrapolation is done between the points at which each track enters and exits each gas volume to obtain the true position for that wire plane and thus the expected coordinate in the associated eta and phi strip planes. This is done using the CscClusterValidator algorithm. Segment predictions are obtained in a similar way using the entrance and exit points for the chamber.

The CscHitValidation package contains the algorithm CscHitValidator which takes Monte Carlo hits as input and writes a root tree containing the hit data, cluster predictions or segment predictions. Check out and build this package and then run athena with the job options in the following table.

output job options output tree file Monte Carlo hits CscHitValidatorOptions.py csc_simhit.root Monte Carlo cluster predictions CscSimPosValidatorOptions.py csc_simpos.root
For example, if the software is installed in $HOME/MuonSpectrometer/MuonValidation/MuonCscValidation

> athena.py $HOME/MuonSpectrometer/MuonValidation/MuonCscValidation/CscHitValidation/share/CscSimPosValidatorOptions.py dataset.py

will produce a tree file with cluster predictions, i.e., csc_simpos.root . The file dataset.py lists the files you want to process.

Segment predictions may be produced directly from the cluster position predictions:

> csc_simseg_builder.exe csc_simpos.root   >& log.log & // creates csc_simseg.root

There is also an algorithm to produce the segment predictions directly from the hits, but (starting in February 2007) it provides less information and its use is no longer recommended. In particular, it does not carry the truth kinematic information used to make performance cuts.

Note that the hit, cluster and segment positions and directions int the trees are in the muon coordinate system where x is normal to the chamber, y in the direction measuring phi and z in the direction measuring eta.

Cluster measurements

Cluster measurements are obtained by reading an RDO file, running a clustering algorithm and then looping over the output of the latter. This is done by algorithm CscClusteringValidator in package CscClusterValidation. The output is the cluster tree file csc_clusters.root.

To run the validation algorithm, add the following to your job options:


after the lines to run a clustering algorithm.

Or the job options file CscClusterValidatorOptions.py may be used to both run the clustering and generate the cluster tree file.

Cluster performance

The package CscClusterPerformance contains an executable csc_cluster_performance.exe that reads a cluster prediction tree and a cluster measurement tree and, event by event, matches these and write the output to the cluster performance tree csc_perf.root.

Segment measurement

> athena.py $HOME/MuonSpectrometer/MuonValidation/MuonCscValidation/CscSegmentValidation/share/CscSegmentValidatorOptions.py dataset.py

Segment performance

The package CscSegmentPerformance contains an executable csc_segment_performance.exe and csc_4d_segment_performance.exe that read a segment prediction tree and a segment measurement tree and, event by event, matches these and write the output to the cluster performance tree csc_segperf.root and csc_4d_segperf.root.

Creating and reading Ntuples


fork athena and run the setupCSC.sh-script inside your desired directory:

run locally over a test (ESDM_MCP)file. The setup script should have downloaded one test file and modify the runJobs file already. Otherwise download one yourself.

cd ../data
rucio get --nrandom 1 data17_13TeV:data17_13TeV.00339957.physics_Main.merge.DESDM_MCP.r10258_p3412
cd ../run/
modify inputfiles in runJobs.test.py and run athena
athena runJobs.test.py
or run on grid
lsetup panda 
 pathena runJobs.test.py --inDS data17_13TeV:data17_13TeV.00339957.physics_Main.merge.DESDM_MCP.r10258_p3412 --outDS user.${USER}.data.00339957.CSCntuple.1 --supStream GLOBAL --extOutFile ntuple.root --excludeFile='*.git','*.svn','*.pyc'

Afterwards you can look into the ntuple or parse it to the CSCntupleReader.

export PlotDir="some/path/you/like/"
ReadCSCntuple -i 'ntuple.root'
you may take the python plotting script or view the histograms directly in the histogram.root file (last cout from ReadCSCntuple code)
 python ../athena/CSCntuple/python/PlotHistograms.py -i the/path/above/histograms.root
Topic attachments
I Attachment History Action Size Date Who Comment
Unix shell scriptsh setupCSC.sh r2 r1 manage 2.9 K 2018-12-18 - 16:02 StefanRaimundMaschek a setup script to get the CSCntuple package
Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r18 - 2018-12-18 - StefanRaimundMaschek
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback