Inner Detector Tutorials

This topic has been created for the Artemis School on Calibration and performance of ATLAS detectors (Munich, September 15-19, 2008)

Tracking Tutorial

link to tracking tutorial.

Alignment Tutorial

The process by which to align the ATLAS Inner Detector can be split into two main pieces:
  • Run the alignment algorithms, to produce alignment constants.
  • Check the quality and reliability of the produced alignment set.

Inner Detector Alignment Tutorial

The main goal of the alignment is to establish to real positions of all Inner Detector modules/components. Apart from survey data, this can be achieved by means of track-based algorithms which try to minimize the track residuals, defined as the distance between the hit position and the track trajectory.

The Alignment of the inner detector is planned to be done on a 24 hour basis, in order to spot possible detector movements (induced for example by the B-field on-off cycles), and to constantly refined the alignment constant sets. The Alignment is an iterative procedure, and is in general a CPU intensive task: alignment jobs are run on a dedicated pool of 100 CPU on CERN CAF. A shifter will take responsability to run jobs and update constants in the database.

Due to time constraints it will not be possible to deal with the alignment procedure itself in this tutorial, however instruction on how to use the current alignment code are reported in this TWiki.

More information from the ID-Alignment group are available on HyperNews and/or on this Twiki.

For some very nice summary talks on alignment please have a look at Andrea's contribution to this school and Carlos Escobar's contribution from Vertex 2008 Conference.

Please now proceed to the following section.

Inner Detector Alignment Monitoring Tutorial


The main task of the Alignment monitor is to identify as soon as possible alignment failures or problems.

Monitoring is part of the overall reconstruction which runs on the Express Stream. The express stream contains a subset of the physics data, around 10% of the total data volume, which are reconstructed in quasi-real time and looked up promptly before the main (bulk) reconstruction starts. The stream will be used to check the data quality, monitor the status of the detector, monitor alignment and calibration, etc.

This is the action flow (from Express Stream).


  • The processing of the express stream starts almost concurrently to the start of the data-taking of an LHC fill (i.e. after the replication of the first Interval of Validity of the conditions database and the first processing unit to Tier-0). Since the express stream reconstruction is expected to take about a few hours, the express stream reconstructed data is available just after the data-taking of a fill.

  • This first processing of the express stream is performed using a replica of the online database. Updated calibration constants are extracted for a given fill using the calibrations stream(s). They will be implemented in the offline database in a timescale of about 24h.

  • A first pass of data-quality assessment (DQA), or data validation, then occurs. This include cross checks on detector calibration and alignment sets.
  • Regardless of the DQA status, a second pass of express stream processing is performed typically 24h later using the new calibration/alignment constants extracted from the calibration streams. If problems have been found in the first pass of express stream processing, the fixes are implemented (if it is possible to do so in a timely fashion).

  • The processing and DQA of the express stream continues as long as problems are found by the DQA procedure, or if too much delay has been accumulated with respect to data-taking (e.g. a constraint is the Tier-0 disk buffer of five days). The sign-off procedure to give the "OK" for Tier-0 to start processing the bulk data needs to be defined.

  • After signing-off the data of the express stream, the reconstruction of the bulk data can start, and will make use of the latest greatest calibration and alignment sets. The Data Quality Monitoring Framework will then be run on the bulk data.

Database and condition tags (or where are alignment constants saved and stored?)

The ATLAS Geometry Database collect information to be used by Detector Description applications for building various versions of ATLAS detector geometry. Starting with the ATLAS-CSC geometries, the simulation requires both a geometry and a conditions top-level tag. The conditions tags evolve independently from the geometry tags, and can contain different calibration/alignment sets. When events are simulated and a particular geometry is selected, a corresponding compatible conditions tag is automatically chosen. The default conditions tags for each geometry tag are noted in Cool Production Tags. However, it is also possible to use different conditions tags with a geometry tag, particularly during reconstruction, as we will do in this tutorial. Some of the latest condition tags provided and used by the ID-alignment community are described in this TWiki.

More detailed links about DB

Systematic misaligned sets

Residual systematic misalignments could be present even after the alignment procedure has been properly applied. These arise from the fact that some global deformation may leave the residual distributions and the chisquare of the tracks unchanged. In other words, alignment algorithm could be blind with respect to particular distorsions (AKA Weak Modes). This is not a bug-like effect, but an intrinsic limitation of the track based alignment method, which could only be solved by applying some extra constraints to the track reconstruction before running the alignment code. Examples of external constraints are as follows:
  • Use different data samples, in which tracks illuminate differently different part of the detector. This can be realize by using a mixture of collision, cosmic-ray, and beam halo/gas events as input to the alignment procedure.
  • Fit tracks to a common vertex
  • Constraints on track parameters/vertex position (from different tracking systems like Silicon versus TRT, or from mass resonances)
  • Using data from survey data, or optical alignment system (FSI) to constraint alignment parameters
  • ...

Some example of systematic misalignment which may persist after the alignment procedure are shown in the following table:


Corresponding alignment sets have been created as explained here.

The aim of these sets is:

  • to identify Weak Mode impact on physics quantities;
  • to implement strategy to get rid of them in the alignment procedure (for instance the application of the external constraints discussed above), and check their ability to remove Weak-Mode-deformations.

Input dataset

In order to practice with alignment monitoring and to try to identify the main physics impact Weak Mode could have, we will use a sample of simulated Z->mumu (misal1_mc12.005151.McAtNloZmumu.digit.RDO.v12003108) For which some files are available from castor: /castor/*.pool.root.1

In case of problems with CASTOR, a couple of files have been copied in the following location: /afs/

In order to properly run on this sample the following geometry and condition tag should be used:

  • Geometry description: ATLAS-CSC-01-02-00
  • Global conditon tags:
    • Ideal Alignment: OFLCOND-CSC-00-01-00
    • Aligned set from alignment procedure (see detector paper) OFLCOND-CSC-00-01-05
    • Completely misaligned set: OFLCOND-CSC-00-00-00

Systematic misalignment sets could be used on top of the ideal alignment set OFLCOND-CSC-00-01-00, just by overriding the alignment folder tags with the following:

  • Elliptical : Ideal + CSCMisaligned_PhiDeltaR_02
  • Curl : Ideal + CSCMisaligned_RDeltaPhi_02
  • Telescope : Ideal + CSCMisaligned_RDeltaZ_02
  • Twist : Ideal + CSCMisaligned_ZDeltaPhi_02

Check which systematic set (or in general, which condition tag) is available in the release kit
In order to check whether misalignment sets are available in a given release kit (in this case 14.2.20). You can used to AtlCoolConsole from lxplus.
    # setup the release kit for 14.2.20
    #source /afs/ -tag=14.2.20,setup,runtime
    # setup the release used for this school:
    source ~/cmthome/ -tag=AtlasProduction,,opt,32,setup
    # Use "COOLONL_INDET/OFLP200"  (or "COOLONL_INDET/OFLP200;readoracle" )
    >>> cd Indet
    >>> listtags Align
    You will find among others, the following lines in the output:
    InDetSi_CSCMisaligned_PhiDeltaR_02 (unlocked) []
    InDetSi_CSCMisaligned_RDeltaPhi_02 (unlocked) []
    InDetSi_CSCMisaligned_RDeltaR_02 (unlocked) []
    InDetSi_CSCMisaligned_RDeltaZ_02 (unlocked) []
    >>> exit
    Please note that the same holds also for TRT: i.e. "COOLONL_TRT/OFLP200" then cd TRT and listtags Align .

Test job from InDetRecExample

In general alignment monitoring jobs run during the express stream processing and require the complete event to be reconstructed. Some example of complete alignment monitoring output can be find for example at this link (it contains monitoring results produced during one of the latest FDR2 exercises).

However if we are interested in a fast check (i.e. feasible in 1hr period), only the inner detector reconstruction can be involved.

Instructions for running your job

  • login to lxplus
  • source /afs/
  • you will be prompted to a working directory called test_alimon in your home
  • Edit the file
    • Change the Aliset flag in your alignment monitoring jobs
               NOTE: this operation is need at the beginning of the tutorial since we need to allow 
                         some time for the job execution. At this time, it could be senseless, but  
                         it will become more clear in the following (hopefully)...
      # Alignment/misalignment controls
      # Aliset = 0: misaligned (nominal)
      # Aliset = 1: aligned (ideal)
      # Aliset = 2: aligned + Elliptical
      # Aliset = 3: aligned + Curl
      # Aliset = 4: aligned + Telescope
      # Aliset = 5: aligned + Twist (not available in release KIT 14.2.20)
      # Set here your preferred condition tag,
      # See above for description
      # NOTE: Aliset = 5 does not work, since the corresponding
      #                  condition tag is not present in release KIT 14.2.20
      AliSet = 0
    • Eventually the number of events... Please note that running over 100 evts takes normally 5 minutes. Do not exceed 500 events!
  • Run your test job on LSF:
    • bsub -q 1nh
    • check the job status with bjobs and bpeek JOBID.
  • If something goes wrong please do not panic... there will be a backup solution! Please now come back to follow the tutorial! smile

Alignment quality assessment

A good alignment is in general achieved when:

  • track residuals are around zero for different modules/layers/sub-systems
  • track chisquare is around unity
  • no charge asymmetry versus pT is present in end-caps or barrel
  • a "good" resolution is achieved on di-track resonances (J/psi, Upsilon, Z etc...)

Let us see these quantities (or at least some of them) in the case of residual misalignment sets.

  • Login to lxplus
  • cd ~/test_alimon
  • source source_RELEASEKIT
  • root -b "checkAli_InDetRec.C(ALISET, false)" Aliset must be the same used in your athena jobOptions (see before).
  • fall-back solution: if something went wrong about you test job on LSF, you could still run checkAli_InDetRec.C by setting the second argument to TRUE. In this case you will run over some pre-produced alignment monitoring root files.

This will create in your working directory (and in the plots sub-directory) some plots in which the performance of the alignment set used in your reconstruction job is compared to the case of an IDEAL alignment.

You can look at the (using gv) or at Out_ideal_vs_YOURMISALIGNMENT.root (via ROOT).

What you will find in these plots:

  • Track Efficiencies plots,
  • Residual distributions ,
  • General track parameters, including charge asymmetries and chisquare
  • Z invariant mass, computed using track only (no mu-ID due to the partial reconstruction applied).

What you should note:

  • The statistics is somehow low for a properly comparison of alignment sets (you used only 500 evts), in any case, the general behavior is in most case anyway visible. You can look at this page for larger statistics plots

  • Curl:
    • Residuals/efficiency distribution are very close to the ideal case
    • A bias (~50 microns) is introduced to the track impact parameter distribution
    • Charge asymmetry versus pT is observed in the both end-caps and barrel
    • The Z invariant mass peak is shifted and a degradation in the resolution is observed

  • Twist:
    • In the current misaligned set, residual distributions for TRT is biased
    • Charge asymmetry versus pT is observed which opposite directions in the end-caps
    • The Z invariant mass peak is shifted and a degradation in the resolution is observed

  • Elliptical:
    • No deformation or changes in hit efficiency, residuals, track parameter or Z mass. With the size of the deformation implemented in the current mis-aligned set, it seems that this Weak Mode has really a poor impact on physics performances.

  • Telescope:
    • Residuals are biased in the silicon barrel -> could be probably removed by alignment procedures.
    • Bias on physics is barely visible, also this mode seems to have poor impact on physics performances.


Many thanks to Ben Cooper and Tobias Golling for their advice about ID-monitoring, to all the ID-alignment community for their useful help and comments, and to the organizers of this nice school.

Vertexing and b-tagging Tutorial

link to b-tagging tutorial.

-- GiorgioCortiana - 02 Sep 2008-- GiorgioCortiana - 15 Sep 2008

Topic attachments
I Attachment History Action Size Date Who Comment
GIFgif ali.gif r1 manage 22.2 K 2008-09-05 - 11:05 GiorgioCortiana  
PNGpng alignflow.png r1 manage 166.8 K 2008-09-02 - 14:59 GiorgioCortiana  
JPEGjpg alignment3_511.jpg r1 manage 31.2 K 2008-09-03 - 14:09 GiorgioCortiana  
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r12 - 2008-09-16 - GiorgioCortiana
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 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