## Feature #1696

### Tracker to tracker alignment

Status:
Closed
Priority:
Normal
Start date:
19 June 2015
Due date:
% Done:

100%

Estimated time:

Description

We had some discussion about looking at the tracker to tracker alignment data:

• Adam Dobbs agreed that he would fix the pattern recognition as a matter of urgency
• Chris Hunt agreed that he would try to get Kalman fit and do a first crude fit of the data from Thursday night run 07050 and any stuff we take tonight/over the weekend

Files

#### Updated by Hunt, Christopherabout 9 years ago

I have written a script which extracts and examines the straight reconstructed straight tracks.

It uses up the upstream tracker to extrapolate to the downstream tracker and examine the residuals.

Attached are two plots of the residuals in position and gradient following the extrapolation. I have used a test geometry with a known misalignment to demonstrate what we could see.

The script correctly reconstructed the misalignments to within roughly 0.01 degrees.

#### Updated by Hunt, Christopherabout 9 years ago

I have also had an idea on how to geometrically describe the misalignment:

If you draw a line between the centres of the two trackers you can calculate the deviations of each tracker axis from this imaginary line. I have been calling the upstream angles alpha and downstream angles beta, so we reconstruct alpha_x, alpha_y, beta_x and beta_y. Still need to look in the rotations around z, but its ready to go!

My example 10,000-muon run found:
Alpha_x = 2.001 deg (actual 2 deg)
Alpha_y = -0.796 deg (actual -0.8 deg)
Beta_x = -1.494 deg (actual -1.5 deg)
Beta_y = 2.006 def (actual 2 deg)

I'll be running it on data today hopefully.

#### Updated by Hunt, Christopheralmost 9 years ago

First pass with data set 07103. The verification looks pretty nice (see the Kalman Smoothed Residuals plots) maybe some issues in the downstream tracker, TBC.

Using the previous definition of Alpha and Beta angles (rotations of the up and downstream tracker with respect to the line between the tracker centers), the misalignment seems to be less than 1 degree. There is no error estimate for this and only 261 tracks, but its a first.

Alpha-x = -0.12 deg
Alpha-y = 0.17 deg
Beta-x = -0.05 deg
Beta-y = 0.08 deg

#### Updated by Hunt, Christopheralmost 9 years ago

Forgot some plots.

#### Updated by Rogers, Chrisalmost 9 years ago

Just a feature to bear in mind - we agreed during the analysis parallel that the line between centre of upstream tracker station 5 and upstream tracker station 1 would define the beam axis of the experiment.

#### Updated by Rogers, Chrisalmost 9 years ago

Nb your misalignment is 2-3 mrad, which is around about what jhc was quoting at least order-of-magnitude wise. What is your estimated position alignment?

If you tell me how you define alpha and beta I can compare with the estimated alignment of the bore (or you can see slide 31 and 32 of https://indico.cern.ch/event/374187/session/6/contribution/29/material/slides/1.pdf

#### Updated by Hunt, Christopheralmost 9 years ago

The simplest maths I found was to relate the rotations of the trackers the imaginary line drawn between the center of the upstream tracker and the center of the downstream tracker. So in effect positional shifts of the bore are represented as rotations that appear opposite in each of the trackers.

Alpha_x is the rotation of the upstream tracker in the x-z plane, alpha_y is the upstream rotation in the y-z plane. Beta_x is the rotation of the downstream tracker in the x-z plane and beta_y is the downstream rotation in the y-z plane.

I will change the code to reflect the outcome of the analysis meeting. Owing the the speed at which I put this together and tested it, I would be very wary of having the wrong sign for 1 or 2 values. I still need double check my workings!

#### Updated by Hunt, Christopheralmost 9 years ago

Just a quick one. There are a couple of assumptions made in this but we're getting there. Error estimate to come soon.

These results should relate the downstream tracker the upstream tracker coordinate system. They are however under development. This is an update with about 3500 tracks and the correct coordinate description.

The results are showing a shift of :
-14.15 mm in X
+7.87 mm in Y

and a rotation (about the reference plane centre) of :
-2.78 rad in the X-Z plane (0.15 deg)
-1.09 mrad in the Y-Z plane (0.06 deg)

The spread in the X-Y residuals is very large and makes the X and Y shifts the weakest measurement. The spread in the gradients is much tighter. There is also slight issue in the calculation of the shifts - I think I missed a small correction factor off so the order of magnitude should be pretty good, but its likely to be improved.

I will upload plots and errors and hopefully some improved numbers as soon as I have a faster internet connection!

#### Updated by George, Melissaalmost 9 years ago

Kalman is looking very good. Nice to see. We must be careful to wait for the calibration of the DS Tracker to be complete before drawing any strong conclusions. The alignment analysis will be run when this is complete and hopefully we will see confirmation of Kalmans results. Melissa

#### Updated by Long, Kennethalmost 9 years ago

Notes on meeting to progress checking of tracker hw/ and s/w.

#### Updated by Long, Kennethalmost 9 years ago

Notes on second tracker performance discussion.

#### Updated by Hunt, Christopheralmost 9 years ago

Plots following the meeting on 2015-07-30

Note: Chi-Squared plots are NOT per degree of freedom - the calculation needed correcting (done and recompiling to check. I will push my branch with this fix later today)

#### Updated by Hunt, Christopheralmost 9 years ago

Updated plots with zero suppression turned off. I keep receiving CPU errors from the batch cluster from running out of memory due to the volume of data. Code could probably use some streamling before we try it again.

Still haven't got the ADC Saturation cut in - need to re-run with the updated data structure.

#### Updated by Rogers, Chrisalmost 9 years ago

Just so you know how the NPE per cluster should look like, ref section 5.3 in the tracker paper:

http://www.sciencedirect.com/science/article/pii/S0168900211008126?np=y

#### Updated by Rogers, Chrisalmost 9 years ago

And another thing... see the excellent quality "art" art.png

I think that if you believe that I got the "cell period" right, and we have completely paraxial tracks, then 1 in 7 should be a two-hit cluster and 6 in 7 should be a one-hit cluster.

#### Updated by Hunt, Christopheralmost 9 years ago

Updated plots. No zero suppression, if a digit has ADC == 255 it is ignored from all NPE plots, but included otherwise.

#### Updated by Hunt, Christopheralmost 9 years ago

The number of digits per clusters plot has low stats and appears to be different for every plane. Now that I have an couple fixes that seem to work I can (and will) add more stats.

#### Updated by Overton, Edwardalmost 9 years ago

Hunt, Christopher wrote:

The number of digits per clusters plot has low stats and appears to be different for every plane. Now that I have an couple fixes that seem to work I can (and will) add more stats.

Chris R, I'd submit that to the national gallery!

Also Chris Hunt, nice work on the 255 thing. The NPE plot looks much nicer now.

The clusters plot (from before) looked a little odd, I have a couple of questions:
a) do we apply a cut to clusters, or is that only to digits? (should the peak at 0 be there)
b) why is the light yield of a cluster so delta-function like? Its hard to see how we got from the npe plot to the cluster npe plot.

Would it be possible to get the npe_cluster_raw.pdf on a log-y, and going out to 25 or so on the x-axis?

#### Updated by Hunt, Christopheralmost 9 years ago

Ed,

The analysis ignores clusters where any of the digits saturate the adc count. So if actual hits are next to some noise, they get discarded. I think that might be whats happening. New log-plots attached.

#### Updated by Hunt, Christopheralmost 9 years ago

Also there is a cut applied to clustering. It is set to some NPE value/2 - but I think that by default it is set to 2 - so it only clusters digits that are guaranteed to add up to 2 or more. So really there should not be a peak at zero, the plot should start at 2?

I'm going to look into this.

#### Updated by George, Melissaalmost 9 years ago

Plots to show Doublet spacepoints vs triplet spacepoints. Ratio and by station added. ATM this is for one run 7157 200MeV muon run. When i get to grips with TChain in python it can be all muons

#### Updated by George, Melissaalmost 9 years ago

Plots to show number of digits per station and spacepoint per station for each of the pion runs taken. These are non weighted.

#### Updated by Hunt, Christopheralmost 9 years ago

All plots in the tar file are for non-zero suppressed data. Please feel free to have a look and find the errors.

I am no looking at the clustering algorithm to findout what a zero-npe cluster is!

#### Updated by Rogers, Chrisalmost 9 years ago

Attached note justifying the alignment statistical precision/number of muons required. Quote 36000 good tracks between upstream and downstream trackers.

#### Updated by Rogers, Chrisalmost 9 years ago

Correction - I got better numbers for the He windows. I am running an MC at the moment to back up these numbers. I will try to do the "earth's magnetic field" correction by lunchtime...

#### Updated by Hunt, Christopheralmost 9 years ago

So it seems the mysterious zero-pe clusters were an artefact of some little bug in the data structure or the python wrapping. If I use the clusters' native NPE variable you get the attached plot - much nicer! Otherwise I think it might be linking to the wrong digits, or just to unallocated memory. Need to check properly, but for now this seems to work.

I have also attached the plot of RAW ADC values from the digits. Possibly not the most useful without the calibration applied, but its nice to get a feel for how many are saturating.

#### Updated by Rogers, Chrisalmost 9 years ago

Chris Hunt, we need to tell operations how many good tracks we have. Can you let me know what is your best estimate for the number of good tracks, i.e. tracks in both upstream and downstream trackers, for each beam setting?

#### Updated by Hunt, Christopheralmost 9 years ago

Trying to work it out at the moment. Turns out the recon on 07168 (a big one!) failed and I forgot to re-run it. Its happening now.

All Runs:
If we include the reference runs we have at least 60,000 tracks not including 07168 or 07160 - so possibly over 100,000.

200MeV Muon runs:
I've only counted 13,000. But the 07168 is the 300MeV Muon run is a lot larger than the others, but we will have to wait and see. Assuming it is similar to the others we might have 25,000 in total.

Two things are making it difficult:
• The transmission - less than 1 in 3 muons makes a downstream track.
• Processing time - I have been hitting the processor time limits when reprocessing the data - so is there is probably more to be had than I could find.

I tried to maximize the number of tracks I found, but that wasn't my first priority.

#### Updated by Hunt, Christopheralmost 9 years ago

Plots to enjoy at your leisure.

In the tar file are directories for general recon, patrec, trackfit, and plane-by-plane and station-by-station plots.

So there are now plots for NPE for each channel, NPE per cluster, cluster position per plane, etc. Please have a look through some of then and shout if something looks a little odd, or if there is something obvious missing.

Note - one tar file has zero supression on, and the other doesn't. Zero supression has so much noise its difficult to analyse it in enough detail on its own. So now you can compare!

I think thats all the "easy" things to plot anyway.

#### Updated by Rogers, Chrisalmost 9 years ago

I realise I made an unplanned mistake!

sigma(x) = 27.3

If we want to know position to 50 microns, then

sigma(x) = 0.05 mm

then

(27.3/0.05)**2. = 298116.0

so 300,000 muons

#### Updated by Hunt, Christopheralmost 9 years ago

Sooo, how about pions? We have a lot more of those...

## Track Data/Comissioning Workshop - Brief Overview¶

Yesterday, 06-07-2025, Ed Overton, Chris Heidt and Myself spent the afternoon pouring over the plots that we have collectively produced, and we have made a few big leaps and helped bring some of the interested parties up to speed.

Chris Heidt and Ed both have methods to produce known bad channels (either Hot or Dead) and were comparing notes to ensure that we can generate and use them effectively within the reconstruction

### The "Noise" Problem¶

We discovered that there is an inherit low-level bug in the raw ADCs coming from the channel. Initially we discovered "wiggles" in the ADC Count distribution.

See the discovery plots (ADC_Issue_Discovered.pdf). This was generated with a recent run, using data straight out of the unpacker - no MAUS involvement, you can quite clearly see there are peaks in the ADC distribution for many channels at around 185 counts and 230 counts. In fact they appear precisely every 32 channels!

After much discussion and thinking Ed is reasonably certain that some issues lies in/on/related to the TripT chips in the front end electronics (as they are the only component that has a period of 32 channels).

We discovered that on average 0.4% of events results in these odd ADC values and/or full saturation in the other channels - essentially corrupting the entire tracker event. The other events seem perfectly fine. So we have an easy fix - if you see more that 1000 saturated ADC counts, skip the event, initial tests have shown this seems to work quite well.

Ed is planning on implementing this cut in the unpacker so that analysers need not worry about it, while the experts attack the problem in the next few weeks.

In the meantime the data verification can now proceed a little quicker! New plots to follow soon.

### New MAUS Data Structure Updates¶

Many of the plots required to fully analyse the data have involved values that was not, by default, available in the data structure. I have a branch of MAUS with some small bug fixes in Kalman and updates the data structure which allows information like the ADC count and a direct link between Kalman Tracks and PatRec tracks to be used.

Once it has built and passed some tests I will put the link up for people to examine if they require such functionality.

#### Updated by Hunt, Christopheralmost 9 years ago

New plots, now with the "saturated events" removed from the analysis.

Note that the ADC, and NPE plots now look much healthier, in addition the number of channels per cluster seems to be much more logical, with mostly single channel clusters being produced. The track fits also seem to have improved and the number of spurious spacepoints and tracks have been drastically reduced.

I am now starting to look at higher level recon objects and seeing if the MC tracker alignment can agree with the data tracker alignment plots.

#### Updated by Rogers, Chrisalmost 9 years ago

Don't forget to upload the plots!

#### Updated by Hunt, Christopheralmost 9 years ago

and apparently the second time too.

Ok, so Redmine has decided it doesn't like me. You can download the latest plots from:

www.hep.ph.ic.ac.uk/~ch308/07168_tracker_verification_plots.tar

#### Updated by Rogers, Chrisalmost 9 years ago

Note maximum file size is 145.1 MB... your tarball is 238 MB

#### Updated by Rogers, Chrisalmost 9 years ago

Note that there are some details about the tracker alignment at http://micewww.pp.rl.ac.uk/attachments/3212/Tracker_1_waveguige_log.docx and http://micewww.pp.rl.ac.uk/attachments/3213/Tracker_2_waveguige_log.docx

I upload some personal notes tracker_alignment_v1.pdf tracker_alignment_v1.odt following discussion with Geoff Barber on Friday

#### Updated by Hunt, Christopheralmost 9 years ago

I have re-run the alignment and verification scripts after amending a couple of bugs in the recon code. The accompanying plots describe the new findings.

I also included a cut on the number of trackpoints - set to 15 to ensure that there is precisely one cluster per plane included in the fit and nothing else - this seems to have made the biggest difference to the fit. The smoothed residuals and pulls now look much cleaner an more in line with what we were expected. (Plots included in the tar file)

The tar file also includes plots from the 07168 data set where the X-Y projected residuals (alignment_residual_xy) and Tx-Ty (angles) projected residuals (alignment_residual_txty) are visible. Additionally there is a comparison to a the same plots from a MC data set (alignment_MC_*) and an example diagonal plot of residual X verses residual My (gradient). Difficult to spot a correlation there.

There is also a plot to demonstrate how the tracker separation can be calculated (alignment_tracker_length). The separation is equal to the gradient on the fit.

It is important to note that all the alignment plots are from the second iteration of a recursive calculation - so the numbers look small. I am currently finishing the the details of the calculation in Latex. I will post the note/piece of paper when I've finished.

The values:

Tracker Ref Plane Separation = 2739 +/- 50 mm

Delta X = - 18.11 +/- 0.65 mm
Delta Y = - 41.87 +/- 0.64 mm

Delta Phi-X = 1.28 +/- 0.37 mrad
Delta Phi-Y = 8.58 +/- 0.40 mrad

#### Updated by Hunt, Christopheralmost 9 years ago

I think we may have sorted it this time.

By using the TOF spacepoint positions and looking at the correlations with the trackers I have deduced that the trackers are experiencing a rotation by 120 degrees and some sign flips. This can be completely attributed to the planes being in the wrong order.

As there is a sign flip involved I believe that the mapping file has two planes interchanged - but that is not confirmed, merely one possible explanation. But does mean we can do the alignment calculation with the corrected reconstruction. So:

Delta X = - 1.37 +/- 0.85 mm
Delta Y = 24.46 +/- 0.80 mm
Delta Phi-X = 2.47 +/- 0.44 mrad
Delta Phi-Y = 4.76 +/- 0.39 mrad

The attached plots show the corrected X-Y and Phi-X-Phi-Y residuals after the alignment calculation.

These numbers were calculated using 2452 pairs of tracks from runs 07157 and 07158 with some modest cuts applied:
- Tails cut on TOF1-2 [ 34.0 ns <-> 38.0 ns]
- Required 15 trackpoints per track (Excluding upstream station 3 due to missing bank)
- Assumed a fixed separation of 3663.4mm (a legacy number - need to update and measure with data for comparison)

#### Updated by Rogers, Chrisabout 7 years ago

• Status changed from Open to Closed
• % Done changed from 0 to 100

Also available in: Atom PDF