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

• 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 digit.channel#s 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 http://reco.mice.rl.ac.uk/MAUS-v1.1.1/07417_offline.tar 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?

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.

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?

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.

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.

Ryan

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 the issue to remove the wrong diagrams, just in case someone glances at them in error and misses the warning.

• 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?

Any update on where we are on implementing the fixes?

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.

Chris,

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

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.

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?

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!)

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.

Hi Chris -- yes, sorry, it's

lp:~christopher-hunt08/maus/maus_tracker_recon_fix

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?)

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.

Chris

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.

Fixed a long while ago. Closing the issue.