Project

General

Profile

Bug #1866

Tracker Reconstruction charge assignment error

Added by Dobbs, Adam over 6 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
High
Assignee:
Kyberd, Paul
Category:
Tracker
Target version:
Future MAUS release
Start date:
23 August 2016
Due date:
% Done:

100%

Estimated time:
Workflow:
New Issue

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

8070_az_ad_tku.png (25.3 KB) 8070_az_ad_tku.png Dobbs, Adam, 23 August 2016 15:08
8070_az_ad_tkd.png (29 KB) 8070_az_ad_tkd.png Dobbs, Adam, 23 August 2016 15:08
8155_az_ad_tku.png (26.5 KB) 8155_az_ad_tku.png Dobbs, Adam, 23 August 2016 15:08
8155_az_ad_tkd.png (28.5 KB) 8155_az_ad_tkd.png Dobbs, Adam, 23 August 2016 15:08
muon_direction1.pdf (11.8 KB) muon_direction1.pdf Blackmore, Victoria, 01 September 2016 15:42
muon_direction2.pdf (11.8 KB) muon_direction2.pdf Blackmore, Victoria, 01 September 2016 15:42
muon_direction3.pdf (11.7 KB) muon_direction3.pdf Blackmore, Victoria, 01 September 2016 15:42
muon_direction4.pdf (11.7 KB) muon_direction4.pdf Blackmore, Victoria, 01 September 2016 15:42
muon_charge_direction.pdf (317 KB) muon_charge_direction.pdf Blackmore, Victoria, 01 September 2016 15:42
muon_charge.py (2.17 KB) muon_charge.py Blackmore, Victoria, 01 September 2016 16:08
08070_2-5-1_charge_tkds.pdf (13.6 KB) 08070_2-5-1_charge_tkds.pdf Dobbs, Adam, 02 September 2016 18:10
08070_2-5-1_charge_tkus.pdf (13.5 KB) 08070_2-5-1_charge_tkus.pdf Dobbs, Adam, 02 September 2016 18:10
08155_2-5-1_charge_tkds.pdf (13.6 KB) 08155_2-5-1_charge_tkds.pdf Dobbs, Adam, 05 September 2016 16:09
08155_2-5-1_charge_tkus.pdf (13.5 KB) 08155_2-5-1_charge_tkus.pdf Dobbs, Adam, 05 September 2016 16:09
08070_2-5-1_charge_all.pdf (16.7 KB) 08070_2-5-1_charge_all.pdf Dobbs, Adam, 06 September 2016 17:19
08155_2-5-1_charge_all.pdf (16.7 KB) 08155_2-5-1_charge_all.pdf Dobbs, Adam, 06 September 2016 17:19
#1

Updated by Blackmore, Victoria over 6 years ago

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

#2

Updated by Blackmore, Victoria over 6 years ago

Uploading the script that makes the above plots using the 'extracted data file' from http://micewww.pp.rl.ac.uk/issues/1833

#3

Updated by Dobbs, Adam over 6 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.

#4

Updated by Dobbs, Adam over 6 years ago

Victoria, I am not sure I follow your discussion on run 07469, all seems well to me there. Perhaps a phone chat...

#5

Updated by Dobbs, Adam over 6 years ago

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?

#6

Updated by Dobbs, Adam over 6 years ago

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

#7

Updated by Blackmore, Victoria over 6 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. :)

#8

Updated by Blackmore, Victoria over 6 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)

#9

Updated by Dobbs, Adam over 6 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...

#10

Updated by Dobbs, Adam over 6 years ago

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.

#11

Updated by Rajaram, Durga over 6 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?)

#12

Updated by Dobbs, Adam over 6 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?

#13

Updated by Rajaram, Durga over 6 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.

#14

Updated by Dobbs, Adam over 6 years ago

This shouldn't take long to fix. I will hopefully have a chance to get it done tomorrow. Will let you know!

#15

Updated by Dobbs, Adam over 6 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.

#16

Updated by Dobbs, Adam about 6 years ago

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

Also available in: Atom PDF