LISTSERV mailing list manager LISTSERV 16.5

Help for HPS-SOFTWARE Archives


HPS-SOFTWARE Archives

HPS-SOFTWARE Archives


HPS-SOFTWARE@LISTSERV.SLAC.STANFORD.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

HPS-SOFTWARE Home

HPS-SOFTWARE Home

HPS-SOFTWARE  September 2012

HPS-SOFTWARE September 2012

Subject:

Re: Tracker hits simulation

From:

"Hansson Adrian, Per Ola" <[log in to unmask]>

Reply-To:

Software for the Heavy Photon Search Experiment <[log in to unmask]>

Date:

Thu, 27 Sep 2012 18:17:22 -0700

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (76 lines) , winmail.dat (76 lines)

Ok,
one of these are solved. Tim lectured me on the Lorentz stuff. It's correctly done in Stripmaker. If you want details I can tell you.

/Pelle

On Sep 27, 2012, at 5:53 PM, Hansson Adrian, Per Ola wrote:

> 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

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
June 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011

ATOM RSS1 RSS2



LISTSERV.SLAC.STANFORD.EDU

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager

Privacy Notice, Security Notice and Terms of Use