# OT Mono layer alignment

## Introduction

In his thesis Alexander Kozlinkiy has shown that the OT sense wires are not perfectly centered in the straws. See for example figure 4.22 on page 58:

The figure shows the average residual in the 32 straws connected to one OTIS for the 4 OTIS in one module as a function of the position along the wire in a module. The residual is clearly non-zero and shows jumps at the position of the wire locators. This suggests that the wire locators do not keep the wire in the center of the straw. In between two wire locators the wire is just straight, as expected. The shown example is for a particularly bad module. However, for most modules the displacements are a good fraction of the resolution. When taken at face value, results shown below indicate that the resolution of residuals in OT is worsened by about 20% due to this effect.

What is also shown in the plot is that the displacement is correlated between the two OTIS in one mono layer. It is not entirely clear why this is, but it suggests that one could calibrate for a common shift of all wires in one monolayer. Furthermore, since any common movement or rotation of the monolayers can be absorbed in the module alignment, the calibration could be performed for the difference in the two mono layers.

It is fortunate that the displacements are common to all straws in a monolayer. Because if they were not, it would be impossible to align for them without loosing the constraint on the 'x-scale' in the OT. This is important because the only relevant constraint on the x-scale in lhcb comes from the known detector pitch.

In fall 2014 a renewed effort was made to actually provide a mono layer alignment that can be used for data processing. For a talk , see WH, OT-session of LHCb week of December 2014. This twiki page provides some more in-depth documentation.

## Implementation in geometry

In the nominal geometry (and simulation) all the sense wires in an OT module are parallel and positioned at a fixed relative pitch in x (5mm) and z (5mm). In the nomenclature of the track fit, a hit in a certain wire is described by a 'trajectory', a curve in space. It has a method that returns the position as a function of a parameter 'mu' that walks along the trajectory. It also has methods that return the first and second derivatives of the position to the parameter mu. These are used by 'TrajPoca' to compute the distance of closest approach between two trajectories.

All trajectories in the track fit derive from the base class LHCb::Trajectory. Trajectories can have arbitrary shape. For OT, IT and velo-phi strips, they are straight lines (LHCb::LineTraj). For TT they are collections of straight lines, implemented via LHCb::PieceWiseTrajectory. This is because in the TT multiple strips on different sensors in a ladder are read out as a single hit. For velo-R strips the trajectories describe a segment of a circle (LHCb::CircleTraj). In the pattern reco the LHCb::Trajectory class is not used, but otherwise the hits looks similar: they are either straight lines or circles. (Collections of straight lines, as for TT, are not used.)

The parameters of the trajectory of a hit are provided by the implementations of the different detectors in the LHCb geometry. For the OT this is done in OTDet/DeOTModule. To replace the single line segments by 3-line segments with different parameters for the two monolayers, the DeOTModule class needs to be adapted, in particular:

• it needs a new condition to hold the calibration constants
• it needs to provide a new type of trajectory for the track fit
• it needs to adapt the parameters of the straight line used in pattern reco

Since there are many OT hits in an event (more than of any other tracking detector) it is important that the code is fast, preferably not slower than before the new implementation. For this reason the OT trajectory is implemented as a collection of 3 straight segments with equal length (OTDet/OTWireTraj). The expansion parameter 'mu' is chosen to be the global y-coordinate. The beginning of the first and end of the last segment in y are stored such that the actual segment relevant for a certain my can be computed simply from the fraction between begin and end. (This is substantially easier then the lookup in LHCb::PieceWiseTrajectory, which is more generic but requires a search in a sorted list.) In reality the wire locators are not at exactly 1/3 and 2/3 of the wire. This is not a problem: the beginning and end of the wire as seen by the track fit are different from those used to compute the fraction.

The numbers that parameterize the misalignment of the two monolayers are stored in the condition database. There are at most 6 numbers for each module. These six numbers represent the displacement in X between the two monolayers at the beginning and end of each of the three segments. A single number means that we have only calibrated for a constant shift; two numbers mean a shift at beginning and end of the wire (so effectively a shift and rotation); four numbers means three segments, but with no discontinuities. Best results were obtained when all 6 parameters were used, so that has become the default.

It turns out that 'creating' the trajectory from the mono-layer parameters is a bit consuming because it involves 'local-to-global' transformations. To solve that efficiently, only one two OTWireTraj objects are created, one for the first straw in the first monolayer and one for the first straw in the second monolayer. Trajectories for arbitrary hits are made by 'cloning' these trajectories, and move them in the global frame by a vector that represents the distance between the center one wire and the neighbouring wire in the global frame. (OTWireTraj has a function to 'translate' all sub trajectories by a constant vector.)

As indicated above, in the pattern reco only straight lines can be used. The OT straight lines are determined from two coordinates on the OTWireTraj, namely at position 1/6 and 5/6 between its begin and end point.

## Implementation in database

The monolayer alignment parameters are stored in a separate file in the CondDB, namely in

```    Conditions/OT/Alignment/MonoAlignment.xml
```

To link the condition to the file, a catalog is needed. This has required a modification to

```    Conditions/OT/AlignmentCatalog.xml
```

Finally, to tell the geometry that a condition exists, the geometry xml in DDDB needs to be modified, in particular

```    T/OT/Quarters/QuarterStructureTemplate.xml
```

## Description of calibration algorithm

The calibration algorithm is called 'OTMonoLayerAlignment' and resides in the package Calibration/OTCalibration. The algorithm consist of an event processing step (in ::execute) and an update step (in ::update, triggered by an "UpdateConstants" incident, or by ::finalize). In the event processing, the algorithm:

• takes a track list as input
• sorts the hits in the track by module
• selects modules with exactly one hit in each monolayer and computes
• the two residuals
• the covariance matrix of the two residuals (assuming the track parameters to be fully correlated, which is fine since scattering is small inside the module)
• the derivative of the residual to the six parameters describing the OTWireTraj
• from these: the contribution the first and second derivative of the chi2 to the parameters for this module

The algorithm also fills some histograms that can be used for monitoring.

The math to compute the residual correlation matrix and chi2 derivatives is not entirely trivial, but it is important to get a fast convergence. The correlations between hits in different modules are assumed to be zero, which is fine for this application (in contrast to 'module' alignment, for instance).

To facilitate reusing the tools for parallel event processing developed for the Alignment ('gaudipariter.py'), the chi2 derivatives are stored in an instance of 'AlignKernel/OTMonoLayerAlignData, which in turn is stored in the Gaudi detector store. The gaudipariter.py script can add up these objects from the different threads that do the processing.

In the update step the accumulated derivatives in OTMonoLayerAlignData are used to compute new constants. The constants are written to xml in 'finalize' by the OTWriteMonoAlignmentToXml algorithm. The latter also resides in the OTCalibration package.

Assuming that there is a reconstruction sequence that fills a track list at location 'MyLocation', a minimal configuration would look like

```from Configurables import OTMonoLayerAlignment, OTWriteMonoAlignmentToXml
GaudiSequencer("AlignmentAlgSeq").Members += [
OTMonoLayerAlignment(TrackLocation = MyTrackLocation),
OTWriteMonoAlignmentToXml()
]```

An example option file still needs to be provided.

## Some representative results

For the calibration data was used from the express stream files from runs 117201 - 117245. To reduce the occupancy, only events with less than 6000 OT hits were used. In total 298342 were selected, leading to about 130 M used OT hits. The monolayer alignment was run together with OT module alignment (Tx,Rz) since the two are not entirely independent. Five iterations were needed before the algorithm converged.

This attached pdf file shows average residuals as function of the coordinate along the wire in all OT modules. The residuals were multiplied with a sign depending on the mon-layer (+1 for mono-layer A and -1 for mono-layer B). Therefore, the difference from zero represents the mono-layer distance. The balck points were before and the red points after the calibration.

The effect of the tracking is illustrated in this pdf file, which shows some of the track monitoring plots before and after calibration. In particular, we observe that:

• the RMS of OT residuals becomes smaller by about 20%
• track chi2 become considerably smaller as well. The chi2 probability distribution actually suggests that errors are slightly overestimated
• there are slightly more Long, Downstream and T tracks
• there are slightly more OT hits on the tracks

For further validation, it would be interesting to see if track momentum resolution improved as well. (We do not really expect so, since the 'average' position of two hits in two monolayers on a track does not change. Therefore, the monolayer misalignment do not actually bias the track parameters.)

## Database tags

To use the '3segment' wires with '0' alignment corrections use:

```  CondDB().LatestGlobalTagByDataTypes = ['2012']
CondDB().LocalTags["DDDB"] = [ "ot-20150114" ]
CondDB().LocalTags["LHCBCOND"] = [ "ot-20150114" ]
```

To use the newly calibrated alignment constants, replace the latter by

```  CondDB().LocalTags["LHCBCOND"] = [ "ot-20150115", "ot-20150114" ]
```

For all tags, see this JIRA thread: https://its.cern.ch/jira/browse/LHCBCNDB-528

-- WouterHulsbergen - 2015-01-06

Topic attachments
I Attachment History Action Size Date Who Comment
pdf monoalignplots.pdf r1 manage 4322.0 K 2015-01-06 - 22:40 WouterHulsbergen Mono-layer-signed average residual along OT wires
pdf trackingplots.pdf r2 r1 manage 1294.8 K 2015-01-28 - 09:59 WouterHulsbergen Track monitoring plots before/after mono alignment
Topic revision: r7 - 2015-01-28 - WouterHulsbergen

Welcome Guest

 Cern Search TWiki Search Google Search LHCb All webs
Copyright &© 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