Bug #1866
Tracker Reconstruction charge assignment error
100%
Description
From François:
I have looked at the phase advance for run 8070 (ECE up and down, flip mode) and in run 08155 (ECE up and down + FC, solenoid mode) and I find the expected gyration in both of them. I attached the plots for the up and downstream phase advance, purely global spacepoints.
There seems to be an issue with the sign reported by the tracker reconstruction, however, as it reports -1 upstream and +1 downstream in flip mode (instead of +1, -1, given the wrong field downstream) and the same in solenoid mode (instead of +1, +1, given the right field up and down).
Files
Updated by Blackmore, Victoria about 7 years ago
- File muon_direction1.pdf muon_direction1.pdf added
- File muon_direction2.pdf muon_direction2.pdf added
- File muon_direction3.pdf muon_direction3.pdf added
- File muon_direction4.pdf muon_direction4.pdf added
- File muon_charge_direction.pdf muon_charge_direction.pdf added
I had a short look at this for run 7469, where the charge is also reported as being -1.
I plotted the (x, y) positions of the first 25 particles, changing the colour of the blips for each station. I've uploaded the plots as muon_charge_direction.pdf. Colours are:- Station 5 (most upstream) = red
- Station 4 = green
- Station 4 = cyan
- Station 2 = blue
- Station 1 (most downstream) = black
On a few of them I've drawn arrows indicating their direction of travel from upstream to downstream, but as best as I can tell, being naive, they all travel clockwise from up- to downstream.
About a month before run 7469 was taken, Mark Palmer recorded the field direction of SSU. I uploaded a picture of his logbook to https://micewww.pp.rl.ac.uk/elog/SSU/70 He used a 3-axis Hall probe, whose instructions claim that it reports a positive value when the field enters the probe. From his notes, I think that the Bz component of the field also travels from upstream to downstream.
So, if we're looking from Station 5 to Station 1, up- to downstream, I get particles going clockwise. The field is going "into the page", upstream to downstream. The only way that works is if the muon is negative (so the track fit returns the right charge if all of the above is correct).
- The beamline was, and still is (I've looked), in positive polarity. So I don't believe we actually had negative muons.
- I believe we can write down the number we see on a gadget correctly...
- But (!) I'm going to repeat this again when SSU gets powered at 5A tonight and see what I see
- And (!) Craig has ordered me a pretty bar magnet with defined North/South to it so that we can confirm the Hall probe works the way we think it works.
- ???
So, the most reasonable conclusion is that muon_charge_direction.pdf is actually the wrong way around -- and OK, it's pretty obvious, looking up- to downstream, positive x increases towards the MLCR (right handed co-ordinate system), so positive x is "left", whereas in muon_charge_direction.pdf positive x is "right". [Is this the assumption patt rec uses when it assigns a charge?] So the assumption that I'm looking up- to downstream in muon_charge_direction.pdf is very probably wrong.
To confirm, I made a 3D plot of the first particle (so the top left in muon_charge_direction.pdf). These are the plots "muon_directionX.pdf", where X = {1, 2, 3, 4}- muon_direction2.pdf shows the same type of view as in muon_charge_direction.pdf, where the helix direction looks "clockwise".
- muon_direction4.pdf shows what I think an upstream to downstream view looks like, and here the helix is anticlockwise, as a good positive particle should be. The hits proceed in z increasing away from you.
- muon_direction(1,3).pdf are there to help you orient yourselves...
So, moving to a 3d plot, yes.. we have positive muons moving in a field that does go from up- to downstream. But if you were just to do a straightforward (x, y) plot you'd get it wrong.
But to cover all bases, this is what I'm doing:- Check 3-axis Hall probe using a bar magnet to determine the direction of "positive" field
- Measure SSU at 5A (with photographic evidence of the probe orientation)
- Measure SSU at 3T (with a reading written in pencil you'll just have to trust)
- Check direction of muons with next data...
- (And make sure the BLOCs haven't just taken someones word for it that the beamline is positive. Someone could've snuck in there between now, when I just checked, and next Monday!)
Will update once I have some proof of the direction SSU's field is currently facing in (so we don't make two mistakes that magically cancel out)
(Sure, this is all the same as just looking at the phase increase, but it does help me visualise it this way and is hopefully helpful! :) )
Updated by Blackmore, Victoria about 7 years ago
- File muon_charge.py muon_charge.py added
Uploading the script that makes the above plots using the 'extracted data file' from http://micewww.pp.rl.ac.uk/issues/1833
Updated by Dobbs, Adam about 7 years ago
Hi All,
I have started looking into this. First up I confirm the bug seen in run 08070, the charge is indeed wrongly recorded in TkDS using the official MAUS 2.5.1 recon. The code which is used to determine the charge is found at line 749 and onwards of PatternRecognition.cc:
int charge; if (spnts[0]->get_tracker() == 0) { if ( _bz_t1 > 0 ) { charge = handedness; } else { charge = - handedness; } } else { if ( _bz_t2 > 0 ) { charge = - handedness; } else { charge = handedness; } }
handedness is in turn determined starting at line 924 of the same file:
// If we have found a value of n which was accepted, calc the true turning angles if (found) { if ( true_n < 0 ) { handedness = -1; } else { handedness = 1; }
where n is the number of complete turns a particle makes over the length of a tracker. Positive or negative senses of rotation are just determined from the definition of the turning angle in SciFiTools.cc starting line 43:
double angle = atan2(ypos - circle.get_y0(), xpos - circle.get_x0()); if ( angle < 0. ) angle += 2. * CLHEP::pi;
i.e. x rotating towards y (anticlockwise) is considered positive.
No solution yet, will let you know.
Updated by Dobbs, Adam about 7 years ago
Victoria, I am not sure I follow your discussion on run 07469, all seems well to me there. Perhaps a phone chat...
Updated by Dobbs, Adam about 7 years ago
- File 08070_2-5-1_charge_tkds.pdf 08070_2-5-1_charge_tkds.pdf added
- File 08070_2-5-1_charge_tkus.pdf 08070_2-5-1_charge_tkus.pdf added
Hang on, I may be confused, attached are my results for looking at the charge for run 08070. Isn't this what it should be?
Updated by Dobbs, Adam about 7 years ago
- File 08155_2-5-1_charge_tkds.pdf 08155_2-5-1_charge_tkds.pdf added
- File 08155_2-5-1_charge_tkus.pdf 08155_2-5-1_charge_tkus.pdf added
OK I have now reviewed the official processed data for run 8155 as well, again with MAUS 2.5.1. The results show when looking at pat rec helical tracks we see a charge of +1, +1 (and a few mis-ids) as I believe we expect for that run - histos attached. Ball is now back in the analysis team's court to demonstrate the error :) (Was it from looking at Kalman tracks?)
Updated by Blackmore, Victoria about 7 years ago
Hi Adam,
Regarding run 7469: If you look at the direction of the helix, you get the right sign of particle. However, the track fit "charge" function tells me it's a negative muon, so all is not well. :)
Updated by Blackmore, Victoria about 7 years ago
Blackmore, Victoria wrote:
Hi Adam,
Regarding run 7469: If you look at the direction of the helix, you get the right sign of particle. However, the track fit "charge" function tells me it's a negative muon, so all is not well. :)
(I should specify that I get -1 from the track fit, not pattern recognition)
Updated by Dobbs, Adam about 7 years ago
Thanks Victoria. I bet that is it then - the track fit messes up the charge, but pat rec gets it right. If so the fix should be easy. I'll just check...
Updated by Dobbs, Adam about 7 years ago
- File 08070_2-5-1_charge_all.pdf 08070_2-5-1_charge_all.pdf added
- File 08155_2-5-1_charge_all.pdf 08155_2-5-1_charge_all.pdf added
Yup, that proves it. Take a look at the attached files, the top row in both is the charge according to pat rec, the bottom row according to Kalman. Pat Rec shows the correct charge, Kalman gets it wrong. Fix should be to just get Kalman to take the Pat Rec charge.
Updated by Rajaram, Durga about 7 years ago
For my own understanding, I'm curious -- how does PatRec get the correct charge for 8070 (SSD flip)? Asking because we know that the CDB currents specify SSD=solenoid [ when in fact it was flip ]. Doesn't it mean it would have the wrong Bz and hence the wrong charge (based on the code snippet you posted earlier?)
Updated by Dobbs, Adam about 7 years ago
Hi Durga,
Yes, that is exactly what we see (sorry if my terms were confusing). We see the wrong charge for 8070 in TkDS from Pat Rec (that is, -1 is seen not +1 as the beamline was set to) and the correct charge in TkUS. This means Pat Rec is identifying the charge correctly because as you say the field is the wrong polarity in TkDS for that run. Kalman is just wrong as it has TkUS set to -1, and TkDS to +1 (I would guess it flips the pat rec charge). Does that make sense?
Updated by Rajaram, Durga about 7 years ago
Ah, yes ok my bad, I missed that.
What I'd like to do is fix/retrofit the CDB so that SSD=flip for those runs, but I'd like to do it when things are 'quiet' -- i.e. when you let me know it won't affect your debugging.
Updated by Dobbs, Adam about 7 years ago
This shouldn't take long to fix. I will hopefully have a chance to get it done tomorrow. Will let you know!
Updated by Dobbs, Adam about 7 years ago
OK, have a fix in place. Checked it against runs 8155 and 8070 and all seems well now. Just running the tests, then will push to the merge branch.
Updated by Dobbs, Adam over 6 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100