| FairHit::SetPositionError [message #15912] |
Mon, 03 March 2014 18:57  |
MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Dear all,
I am currently wondering if I should set the position error for FTS hits in the FTS pattern recognition. If so, how should the 3 numbers which I can set be interpreted? Uncorrelated standard deviations in cm?
Kind regards,
Martin
|
|
|
|
|
|
| Re: FairHit::SetPositionError [message #15917 is a reply to message #15916] |
Tue, 04 March 2014 17:22  |
MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
|
first-grade participant |
From: *physik.uni-giessen.de
|
|
Thank you Stefano,
do I understand correctly that I should not set the position errors of the FTS hits? My idea was that my PndFtsTrackerTaskHough task sets the errors of each FTS hit according to the geometry of the corresponding FTS straw (read out from PndFtsTube) and my PndFtsHoughTrackCand class uses this information for setting the position error necessary for the FairTrackParP constructor when I create the PndTrack objects.
If I can set the position error of the hit in my tracking task PndFtsHoughTrackCand does not need to know about the FTS geometry. Otherwise I believe that I will have to pass a pointer to a TClonesArray (containing the pointers to PndFtsTube) from my PndFtsTrackerTaskHough to my PndFtsHoughTrackFinder class and then finally to the PndFtsHoughTrackCand class.
PS: I agree that the error on the isochrone is the most important value. However, from the point of view of PR I believed that a hit might be associated to the wrong track candidate and therefore, the geometry of the straw should define the error, but I might be wrong.
PPS: I didn't fully understand what you meant with "And it is better to not rewrite the hit TClonesArray."
[Updated on: Tue, 04 March 2014 17:25] Report message to a moderator |
|
|
|
|
|
|
|
GSI Forum
Search
Help
Members
Login
Home
