Responsible: YuriyPakhotin

Complete: 5

Introduction

Performing routine alignments or even alignment systematics tests usually involves running a high-level procedure and studying standard output plots. However, it is often necessary to "look under the hood" at a part of the system or create ntuples (TTrees) to study a particular topic. Ntuples would use too much disk space in the full system, so a special analyzer has been created for these tests.

The analyzer, StandAloneTest, can be found in the Alignment/MuonAlignmentAlgorithms/test directory. It is a minimal-but-working skeleton. The idea is that it can be modified in a private directory for every individual study.

Overview

When running alignment the standard way, a special CMSSW tool called the EDLooper is invoked, which completely takes over the flow control of cmsRun. The intention was to allow multiple iterations over the dataset within a single cmsRun invocation (not used) and to modify the geometry while still refitting tracks (also not used). Access to the data is available through special alignment plug-ins. All of this is unnecessary overhead if you just want to make an ntuple.

This analyzer is configured to do the minimum necessary to get the same input data as a standard alignment job. This is

  • to refit tracks with negligible weights assigned to the muon chambers
  • to loop over the refitted tracks and recalculate residuals.

Track-refitting is performed by an external analyzer--- it is included in the analyzer's configuration file, configured exactly as in a real alignment job. The negligible fit-weights would normally be set by the EDLooper when that takes over the muon geometry. In this job, we create a muon geometry in a normal SQLite file with negligible weights assigned to the muon chambers. (Weights are actually controlled by alignment position uncertainties, which is a part of the muon geometry.) Trajectories from refitted tracks are associated with the original tracks in the analyzer's loop over tracks. Residuals are calculated by exactly the same tools as the alignment job.

Getting started

Check-out, compile, and set-up

In CMSSW_3_2_X or later, use the following recipe.

cd CMSSW_3_2_X/src
cmsenv
cvs co -r V00-07-15 Alignment/MuonAlignmentAlgorithms   # or a later version
scramv1 build
cmsRun Alignment/MuonAlignmentAlgorithms/test/convert_APE1000cm_cfg.py

The last cmsRun command creates APE1000cm.db, a muon geometry with large Alignment Parameter Errors (APE) assigned to all chambers, superlayers, and layers. The APE will be used in the next step.

Running StandAloneTest

The following script runs StandAloneTest and creates a ROOT file containing the ntuple.

cmsRun Alignment/MuonAlignmentAlgorithms/test/standAloneTest_cfg.py

The output

The output is a standard ntuple in ROOT.

root -lb standAloneTest.db
root [1] TTree *ttree = _file0->Get("StandAloneTest/ttree")
root [2] ttree->Scan()
...

Making modifications

It is assumed that 100% of the users of this system will need to modify it in some way. As such, it has been heavily commented.

Modifying the configuration file

The file Alignment/MuonAlignmentAlgorithms/test/standAloneTest_cfg.py has three parts that you may want to change:

  • the input files (process.source and process.maxEvents, self-explanatory or standard CMSSW)
  • the input source: cosmic rays versus collisions. There are two blocks defining process.TrackRefitter. Uncomment only one of them.
  • the muon geometry or other constants. The process.GlobalTag.globaltag should be familiar to most CMSSW users (see SWGuideFrontierConditions for a list of valid conditions; note that they are different for data and Monte Carlo). A commented-out block would replace the muon geometry with a custom geometry from an SQLite file if uncommented.

Modifying the code

The file Alignment/MuonAlignmentAlgorithms/test/StandAloneTest.cc contains all of the code for this analyzer.

Note: the Track object is the original, un-refitted track. All track-parameters from the Track correspond to the globalMuon, which includes muon hits in the fits. The Trajectory object has been refitted, and is used to calculate the residuals.

Adding ntuple variables

Ntuple variables must be declared (in the class declaration at the top), booked (in the constructor), and filled (in the analyze method). Follow the examples.

Reading data from DT chambers

The example only covers CSC chambers. Working with DT data is analogous, with a few exceptions described here.

DT residuals are treated as two independent objects: their superlayer 1 and 3 data (measurements in the transverse plane of CMS) and their superlayer 2 data (measurements in longitudinal direction, parallel with the beamline), if present (station 4 has no superlayer 2 data). These are MuonChamberResidual objects and can be retrieved from MuonResidualsFromTrack by

MuonChamberResidual *dt13 = muonResidualsFromTrack.chamberResidual(*chamberId, MuonChamberResidual::kDT13);
MuonChamberResidual *dt2 = muonResidualsFromTrack.chamberResidual(*chamberId, MuonChamberResidual::kDT2);

It is up to the user to check that chamberId corresponds to a DT chamber, and that dt13 and dt2 are not NULL (just like the CSC example).

The DetId subclass for DT chambers is DTChamberId. All of the information about a chamber's DetId can be found from the following:

if (dt) {
    DTChamberId dtid(chamberId->rawId());
    int wheel = dtid.wheel();        // wheel -2, -1, 0, +1, +2
    int station = dtid.station();    // station 1, 2, 3, or 4
    int sector = dtid.sector();      // numbered from 1 to 12 (stations 1-3) or 1 to 14 (station 4)
}
else if (csc) {
    CSCDetId cscid(chamberId->rawId());
    int endcap = cscid.endcap();      //  1 is ME+ and 2 is ME-
    int station = cscid.station();    // ME1, ME2, ME3, or ME4
    int ring = cscid.ring();          // the "2" in ME1/2, etc.
    int chamber = cscid.chamber();    // numbered from 1 to 18 (ME2/1, ME3/1, ME4/1) or 1 to 36 (others)

Naming convention

In physics-level documentation (e.g. the CRAFT paper), the following names apply.

$\displaystyle \Delta x$ dt13->residual()
$\displaystyle \Delta y$ dt2->residual()
$\displaystyle \Delta \frac{dx}{dz}$ dt13->resslope()
$\displaystyle \Delta \frac{dy}{dz}$ dt2->resslope()
$\displaystyle \Delta (r\phi)$ csc->residual()
$\displaystyle \Delta \frac{d(r\phi)}{dz}$ csc->resslope()
$\displaystyle x$ any->trackx()
$\displaystyle y$ any->tracky()
$\displaystyle \frac{dx}{dz}$ any->trackdxdz()
$\displaystyle \frac{dy}{dz}$ any->trackdydz()

More information, such as the $\chi^2$ of the segment-fit, can be found in Alignment/MuonAlignmentAlgorithms/MuonChamberResidual.h

Getting low-level hit data and global positions

Residuals used in alignment are linear fits a track's consistency with the whole chamber. To get the individual-layer data, see hitresid(i), hitlayer(i), and hitposition(i) in Alignment/MuonAlignmentAlgorithms/MuonChamberResidual.h. The index i specifies the layer number (counting from 1 to 12 in DTs).

Residuals used in alignment are in the chamber's coordinate system, but it is possible to convert to the global coordinate system. These functions are prefixed by global_ in Alignment/MuonAlignmentAlgorithms/MuonChamberResidual.h.

-- JimPivarski - 16-Nov-2009

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2011-05-06 - YuriyPakhotin
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic 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