Bug #1792


Added by Overton, Edward over 8 years ago. Updated over 7 years ago.

Target version:
Start date:
10 November 2015
Due date:
% Done:


Estimated time:
New Issue


In order to better understand the x flip in the tracker some investigations have been done.

We looked at the channels which constitute a space point (local tracker coordinates):
0 = 102 (alpha=-6.5)
1 = 166 (alpha=100)
2 = 48 (alpha=-93)

Alpha is the distance from the plane centre. The space point generated in this case is at x = -4.4, y = 103.54.

Plane 0 is the only plane which has a consistent x position. (Durga & Chris Heit think that plane 2 should give x). We looked at other space points and plane 0 gave x each time.

Using Geoffs note: we determined the location of the space point in the MICE global right handed coordinate system to be -6.5. Note that there is a x-flip between local tracker coordinates and the global coordinates. So the spacepoint x location appears to be flipped.

Note I assume by geoffs comment "View of the station onto the polished face of the connector" that means that the polished face is pointed out of the page. This indicates that the page is pointing upstream in the upstream. By this I mean the normal vector of the printed page is pointing upstream from the tracker to tof1.

I need to clarify this with Geoff.


07497_offline.tar (571 KB) 07497_offline.tar Rajaram, Durga, 13 November 2015 14:21
07498_offline.tar (1020 KB) 07498_offline.tar Rajaram, Durga, 13 November 2015 14:21
07500_offline.tar (395 KB) 07500_offline.tar Rajaram, Durga, 13 November 2015 14:21
07501_offline.tar (400 KB) 07501_offline.tar Rajaram, Durga, 13 November 2015 14:21
TrackerMapTest.ods (25.1 KB) TrackerMapTest.ods Overton, Edward, 13 November 2015 14:27
MC_unchanged_upstream.png (11.7 KB) MC_unchanged_upstream.png Heidt, Christopher, 16 November 2015 21:07
MC_unchanged_downstream.png (35.5 KB) MC_unchanged_downstream.png Heidt, Christopher, 16 November 2015 21:07
MC_changed_upstream.png (26.8 KB) MC_changed_upstream.png Heidt, Christopher, 16 November 2015 21:07
MC_changed_downstream.png (35.5 KB) MC_changed_downstream.png Heidt, Christopher, 16 November 2015 21:07
20151114_163006_2.jpg (1.18 MB) 20151114_163006_2.jpg Heidt, Christopher, 16 November 2015 21:15
20151114_162935.jpg (2.36 MB) 20151114_162935.jpg Heidt, Christopher, 16 November 2015 21:15
Tracker1.dat (8.43 KB) Tracker1.dat Heidt, Christopher, 16 November 2015 21:48
Tracker0.dat (8.42 KB) Tracker0.dat Heidt, Christopher, 16 November 2015 21:48
map_file (162 KB) map_file Heidt, Christopher, 16 November 2015 21:48
upstream_MC_recon_position_residual.pdf (15.2 KB) upstream_MC_recon_position_residual.pdf Upstream position residuals from truth Hunt, Christopher, 17 November 2015 11:55
upstream_MC_recon_momentum_residual.pdf (22.9 KB) upstream_MC_recon_momentum_residual.pdf Upstream momentum residuals from truth Hunt, Christopher, 17 November 2015 11:55
downstream_MC_recon_position_residual.pdf (16.2 KB) downstream_MC_recon_position_residual.pdf Downstream position residuas from truth Hunt, Christopher, 17 November 2015 11:55
downstream_MC_recon_momentum_residual.pdf (30.1 KB) downstream_MC_recon_momentum_residual.pdf Downstream momentum residuals from truth Hunt, Christopher, 17 November 2015 11:55
trkswfix.odt (42 KB) trkswfix.odt Notes on fix Overton, Edward, 18 November 2015 14:52
upstream_w_mom.pdf (19.2 KB) upstream_w_mom.pdf Heidt, Christopher, 01 December 2015 20:32
momentum_mc.pdf (23.9 KB) momentum_mc.pdf Heidt, Christopher, 01 December 2015 20:32

Updated by Rajaram, Durga over 8 years ago

Added reconstructed output from Runs 7497, 7498, 7500, 7501
These are from pulser runs, Nov 12, with various bits of the upstream tracker turned off.


Updated by Overton, Edward over 8 years ago

I have attached the details of how the tracker was configured for the runs.

Note that only the indicated station connectors should be generating noise.


Updated by Heidt, Christopher over 8 years ago

I've had a think about the problem and I can't reckon any way around our technical drawing, and assumption of how the tracker stations are installed is wrong. The short of it is the way we measure the rotation of the planes and the way we label are channel numbers are reversed. I've tried to make a figure detailing how it should look, please forgive the ugly MS Paint-ness of it!

It is my belief that the most correct method for fixing this is to alter the channel mapping routine to switch the bulkhead connectors and alter the geometry to change the rotation direction of the planes. This is identical to a rotation about the y-axis.

I have tested this in MC. Since the channels are fixed into position independently of station orientation in the MC we should expect, paradoxically, that a rotation about the y-axis should flip a space/track point's y-position. This is exactly what we see.

Notice the flip in y-position in this uncorrected geometry.  Introducing a rotation of 180 degree about the y-axis though corrects this.


Updated by Heidt, Christopher over 8 years ago

Just adding some simple hand written math that explains the problem as well.


Updated by Heidt, Christopher over 8 years ago

One last update for the night. I'm hoping that these files should correct the issue. The mapping file needs to be placed in /files/cabling folder and whatever configuration file is being used needs to point to it:

SciFiMappingFileName = "map_file"

Just drop the geometry files in to overwrite the current cdb geometry.

If someone can test this before I can, that would be great.


Updated by Rajaram, Durga over 8 years ago

Chris, I will re-process a couple of runs once cdb and mousehole are up again.

Couple of questions:
  • Is your picture (with the connectors) in local tracker coordinates? Or in the MICE global r.h. coordinate system?

But am I misunderstanding that the channel map was previously verified in two ways?

  • you, Ed, Adam looked at "x-offset tracks" going through TOF1 & TOF2, and then based on digits, manually reconstructed spacepoints and found they were flipped thus showing that the flip happens between digits and space.points
    • Can someone repeat and document this on the isssue? i.e. a track going through from TOF1-TOF2 offset in x, are the consistent with the map & drawing? You'd expect to see different sets of channels show up depending on whether you're at +x or -x (Please use which has the correct TOF2 ordering and the current CDB geometry)
  • from Run 7498, the digit channels appear where expected based on the drawing & map, but the space points are flipped in x.

Don't these imply that the map is correct?


Updated by Heidt, Christopher over 8 years ago

My changes put the tracker space points into local coordinates.

We verified the mapping insofar as that the Kuno condition was fulfilled, the digit profile appeared correct, and a check to make sure track points look good. The first two of these methods are self-consistent with the new map and geometry. This is because they are tracker internals. I'm not so familiar with how Chris Hunt checked the track points, but his investigation turned up an error with the plane ordering where the u/x-plane was switched with the w-plane(120), but didn't show a fill in x-position with respect to global coordinates.

This gives us three options, either his study was not sensitive to the x-flip, he didn't notice the x-flip, or the x-flip is a new phenomenon. As far as I know, there has been no change in either the reconstruction, mapping, or the geometry. So if it is a new phenomenon I don't know where it would have arisen. The most helpful thing would be to get a hold of Chris Hunt and find out exactly what he looked at to identify the u-w channel flip.

As for your other statements:

I have done a lot of math going from digits to space points and I can absolutely tell you that the space point reconstruction is behaving as I would expect it to with the inputs it is given.

Run 7498 agrees with the drawing, I agree, but this is exactly what we expect because we designed the software to match that drawing. Essentially run 7498 is a single data point, the tracker, it isn't until we compare against multiple data points, the other detectors, that we find the flip. As I alluded to above, everything that we have done exactly matches the engineering drawing, it is the engineering drawing that seems to be wrong, and from that springs our problem with reconstruction.


Updated by Overton, Edward over 8 years ago

Hi Chris. Thanks for looking at this.

When myself and durga looked at the digits, we saw what we expected, indicating that geoffs drawings were consistent with the mapping / hardware. So I am now concerened that we are introducing a change to the map which is now inconsistent with geoffs drawings.

The other things I agree with, I think that the tracker gemoetry must have been discribed in global coordinates, but the put inside local coordinates introducing the 180degree flip. Am I correct in saying that the tracker geometry should be in local coordinates, but the geometry was input in global coordinates?


Updated by Hunt, Christopher over 8 years ago

I've re-run the MC using the CDB geometry, your tracker0&1 files and it looks like you'e nailed it. Position residuals are good and centered on zero as you would expect. There is a issue with the spread of the momentum reconstruction, but I haven't had time to check that. Regardless that will be independent of the the sign flip. Nicely done!

The attached plots show the residuals of reconstructed MC to the MC truth taken from virtual planes that I embedded into the geometry for each plane.


Updated by Bayes, Ryan over 8 years ago

I was looking at it from the simulation side to deal with the flip in y. My observation is that the reconstruction produces space points consistent with the simulation (MC truth) if you swap the orientations of the V and W planes in reconstruction (the Tracker{n}.dat files) with respect to simulation (the Tracker{n}.gdml files) --- that is to say changing -120 to 120 degrees and vice versa. I suspect that this is the case with Chris' fix of adding the new Tracker{n}.dat.

I don't think that this is a good state of affairs. The local coordinate system should not require a special definition for rotations about Z relative to the rest of the simulation.


Updated by Heidt, Christopher over 8 years ago

Well digits are expected to match Geoff's drawing, digits come from mapping incoming DAQ signal onto Geoff's drawing after all.

Spacepoints are determined within local coordinates, but the geometry is, and should be, in global coordinates.


Updated by Heidt, Christopher over 8 years ago


I don't mean to imply that we need a special rotation, we just need a rotation the other direction in our global position.


Updated by Heidt, Christopher over 8 years ago

  • File new_layout.pdf added

This image explains the solution to all the described problems we have.


Updated by Dobbs, Adam over 8 years ago

  • Category set to Tracker
  • Target version set to Future MAUS release

Updated by Overton, Edward over 8 years ago

Please note, we have found inconsistencies between the hardware geometry and it being implemented in software. There is also a mistake in the calculation of parameter alpha.

Ignore all modified drawings on this page. They are incorrect hypotheses from the debugging process!!!!!!

A full description of the problems are:

1) The channel ordering along the plane is opposite in the s/w to h/w, this can be seen comparing the tracker h/w documentation to s/w documentation and in the reconstruction code. In hardware channels are numbered from right to left, but in software they are treated from left to right.
In the software the station measures a distance α, which is then used to calculate the position of the hit fibre. With the mis-numbering α → - α and leads to a flip in both x and y.
Solution: The calculation of parameter α, will be changed to give the correct value, given the channel numbering system.

2) There is a mistake in the geometry which specifies the plane rotations. The incorrect geometry gives 'v' a -120° rotation and 'w' a +120° rotation, both about z. Again this is inconsistent with the drawings where 'v' should be +120° and 'w' should be -120°. On the drawings the positive direction for rotation is anticlockwise (like normal). This results in y-flip only.
Solution: The correct rotations shall be applied to the geometry.


Updated by Dobbs, Adam over 8 years ago

  • File deleted (new_station_look.png)

Updated by Dobbs, Adam over 8 years ago

  • File deleted (new_layout.pdf)

Updated by Dobbs, Adam over 8 years ago

Updated the issue to remove the wrong diagrams, just in case someone glances at them in error and misses the warning.


Updated by Rajaram, Durga over 8 years ago

Chris, Ed - thanks for sorting this out.
If I understand correctly, the solution is
  • cluster reco code change to reverse alpha, and
  • change to the Tracker0, Tracker1 gdml to swtich v(w) from -120(120) to 120(-120).

Is that correct?


Updated by Rajaram, Durga over 8 years ago

Any update on where we are on implementing the fixes?


Updated by Heidt, Christopher over 8 years ago

My personal goal is before the end of this week. We are still having some problems pinning down the exact cause, but I'm narrowing down the suspects.


Updated by Overton, Edward over 8 years ago


Last week we pinned down the cause of this and everything was consistent. What's happened?


Updated by Heidt, Christopher over 8 years ago

hey Ed,

new information came to light. What we said the other day wasn't wrong, just not complete, I've just about got it wrapped up now. More tonight.


Updated by Heidt, Christopher over 8 years ago

I've implemented the changes, but I'm concerned that it looks like it has introduced a momentum flip. Attached are some plots showing that our position is correct in the upstream tracker (downstream is correct, but not shown) but we have a flip in MC reconstructed vs truth momentum. This was done with a beam centered at x = 50 y =50 and 3% of the total momentum in the -x direction and 3% in the -y direction.

I have not include the data reconstruction in this, but it shows something somewhat similar. I'm still working on writing an analysis package to tease out the details in data.


Updated by Rajaram, Durga over 8 years ago

Chris Hunt -- your branch lp:~christopher-hunt08/maus/maus_scifi_recon_devel has been merged into MAUS.

Does this now close the flip issues in both MC & Data?

Can you upload some validation plots [ distributions at TKU and TKD ] with the fix?


Updated by Heidt, Christopher over 8 years ago

The flip has been fixed, but the fix involved a bug in geometry ("star" problem). That bug has been fixed, it might be in preprod now, if not it will be soon. We are still having an issue with a large residual between reconstructed space/track points and MC truth ("sliding" problem). This is a separate issue from the flip, but potentially has the same root problem as one of the three problems that was causing the flip. This problem is much simpler and we are approaching it with the experience gained from solving the flip problem. I will leave it up to you if you'd like to close this issue or wait till we solve the this "sliding" problem.

I should have some plots kicking around that I can upload this afternoon showing all the problems we have been having (I hope I still do!)


Updated by Hunt, Christopher over 8 years ago

Hi Durga. I rather hope you didn't merge that branch into MAUS - that's my unstable development sandbox.

Do you mean: maus_tracker_recon_fix by any chance?

It fixed a small bug in how the effects of the survey were applied to the rotations of the tracker in the global coordinate system. Now fixed. It solved the "sliding" problem in the downstream tracker, but we currently think that the geometry is the missing piece to fix to upstream tracker.

I believe all the flip issues were due to the geometry. So we are just waiting for Chris Heidt's tests, following the big fix that was merged recently.


Updated by Rajaram, Durga over 8 years ago

Hi Chris -- yes, sorry, it's

that was merged, rev. 1018 of the trunk.

So, if I understand correctly -- the code fixes from this branch, along with the geometry fixes should resolve both the star problem and the sliding residuals problem in the MC.

Is that correct?

Chris Heidt -- have all your geometry fixes been handed to Ryan?

And I hope none of these fixes have disturbed the real data reconstruction (has that been checked yet?)


Updated by Hunt, Christopher over 8 years ago

We had an intersting revalation yesterday:
1. My fix does not solve the problem, infact it makes it worse. -> My bad I'll sort that out.
2. The issue is more subtle than we first thought, it looks like you can't just change a couple of numbers around and have it sorted.

I'm trying to get a new merge branch sorted this weekend - one that does nail down the reconstruction and cleans it up a little.
I will hopefully be talking to Chris Heidt today in an attempt to find the actual cause.

The Data recon should be fine. We've seen nothing that will have any obvious consequences.

We'll do our best to keep you informed.



Updated by Rajaram, Durga over 8 years ago

Thanks for the heads up.

I have removed the changes from the merge of lp:~christopher-hunt08/maus/maus_tracker_recon_fix

Trunk rev.1020

You will have to propose a merge again when you're ready.


Updated by Dobbs, Adam over 7 years ago

Fixed a long while ago. Closing the issue.


Updated by Dobbs, Adam over 7 years ago

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

Also available in: Atom PDF