 |
 |
Hi, this is mostly for the hardcore svt developers I guess. I'm trying to summarize the last 1.5days of looking into the weird effect on the residuals I observed. In doing that I got deep into the reconstruction of hits in the svt, still learning about all the myriads of steps and types involved. There are two versions of the clustering of RawTrackerHits into Strip1D clusters: HPSStripMaker and StripMaker. The former is a copy of the latter and lives in the HPS package. * The HPSStripMaker DOES NOT apply a Lorentz correction * The StripMaker DOES apply a Lorentz correction. The position of the Strip1D cluster, when created in HPSStripMaker/StripMaker is transformed from the "local to parent". This basically means that the local position returned is (u,0,0.16) instead of (u,0,0) which means that it returns the local hit position at the surface of the silicon as (0,0,0) in the local frame is in the middle of the silicon. I had forgot about this and it might be a good reminder for anyone who is doing stuff at this level (I might be the only one right now due to the alignment stuff). Normally (using the recipes on confluence) in our reconstruction of the test run data/simulation we create these Strip1D clusters using DataTrackHitDriver which takes the HPSFittedRawTrackerHits and clusters them using the code in HPSStripMaker.java. These Strip1D clusters are then basically copied over to HelicalTrackStrips (still clusters despite the name) that is the input to the 3D hit making and track fitting and so on. Problem 1) I observed a difference (<few um's) between the position of the HelicalTrackStrip and the Strip1D cluster. This shouldn't happen as it's "basically" a copy. This was because when I was computing the position of my HelicalTrackStrip, meaning I needed to use umeas and origin to turn it into the tracking frame, I didn't apply the "local to parent" correction to the local hit position. Fixing that made they agree perfectly. Problem 2) For the same thing as problem 1) I observed a perfect match when running the "TrackerDigiDriver" which is basically a similar clusterer as the normal one but do not have all the time evolution or APV25 simulation. The solution to this was interesting. The first thing to note is the the "TrackerDigiDriver" uses the StripMaker. The key here seems to be that this applies a Lorentz correction. The "funny" thing is that it seems to exactly cancel out the "swimming" to the the surface of the silicon (at least to the 3 digit which what is needed in my comparison). So that it worked in TrackerDigiDriver is explained. I have an example of that correction below. Problem 3) Is the Lorentz correction correct? I don't understand why the Lorentz correction affect the local w coordinate? The position of the cluster should still be at the surface even if the charge cloud gets corrected for the drift along B. So I would expect that the cluster position still should be w=0.16? Shouldn't the charge will be forced to go more in the bend plane due to the Lorentz force. This should affect mostly the v position (the unmeasured one). For stereo it will also have an effect on u which is not affected at all here…. If you agree with what I'm saying I can look into it more but I didn't have time to go in and look at that in detail today. Perhaps someone has checked this Lorentz correction before? Problem 4) I saw a large discrepancy between the position of the SimTrackerHit and the position of the HelicalTrackStrips. I think Matt and I convinced ourselves that this is ok because we weren't correcting for the fact that the HelicalTrackStrip doesn't know where the hit is in the bend plane. This means that when we convert this into a "3D" position in the tracking frame we only move it according to "umeas". This therefore doesn't take into account the fact that if your sensor is rotated in the tracking frame and the hit actually is far out on your unmeasured direction, you will underestimate the "z" direction of your HelicalTrackHit. This can be large because the hit can be 5cm out from the origin with a stereo angle of 50/100mrad. So to summarize we think it's ok that the way I was calculating the position of the HelicalTrackStrip cannot be directly compared to the SimTrackerHit position which is a 3D position, unless one corrects for the effect mentioned above. Problem 5) Problem 4 highlighted another thing I might be doing wrong in the residual calculation. I need to check that I'm doing the propagation of the track correctly. More on that later. Comment 1) I think we should try to use one single StripMaker? I understand that we might want more features to be used in the clustering with time info so we might consider keeping HPSStripMaker so we might want to patch that with the things needed from the lcsim version? Either way we should make sure the Lorentz stuff is correct and that TrackerDigi uses the same clustering class, this is too confusing (according to me :). If you agree I can work on it. What do you think? /Pelle This is an example of the Lorentz correction that is applied in StripMaker.java to the local hit position: StripHitMaker: Position [ 17.940, 0.0000, 0.0000] ( before parent to local) StripHitMaker: Position [ 17.940, 0.0000, 0.16000] ( after parent to local) StripHitMaker: Position [ 17.940, -0.0037781, 2.7756e-17] ( after Lorentz) you can see that the effect of the "parent to local" transformation get's largely cancelled (at least in w) to a large part by the Lorentz correction. ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the HPS-SOFTWARE list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1