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.

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

Forgot some plots.

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

Notes on second tracker performance discussion.

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 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.

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 plots. No zero suppression, if a digit has ADC == 255 it is ignored from all NPE plots, but included otherwise.

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.

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

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

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!

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

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...

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.

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.

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.

Bad Channels¶

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.

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

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

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)