Home » PANDA » PandaRoot » Bugs, Fixes, Releases » PndLhePidTrack
| PndLhePidTrack [message #10480] |
Wed, 31 March 2010 09:59  |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear colleagues,
I have generated the electron in the 90 < theta < 100 (degree) range
with 2.5 GeV to 3.5 GeV momentum.
Total 945 events are reconstruced with using PndLhePidTrack class from 1000 events. TPC and MVD are simply working. and GEM is not
interested in this kinematic range.
And then Pid Candidate has been compared with MC true.
Pandaroot version is slightly old as the v.7878, that's mean some
bug, which are reported during last month(March), are still within there. However the usage of PndLhePidTrack seems to be ok at reco task!
But in the final check, resolutions are too bad and simply wrong with PndLhePidTrack approach. Momentum resolution is about 20~30%, that is not usual because it must be below 5%.
I'm wondering that PndLhePidTrack is not meaningful in this time.
or is the problem related with sets of bugs with MVDcluster and etc..., that was posted in last few weeks?
So you can see resolutions for momentum, theta and phi.
Thanks.
[Updated on: Wed, 31 March 2010 10:02] Report message to a moderator |
|
|
|
|
|
|
|
|
|
| Re: PndLhePidTrack [message #10535 is a reply to message #10488] |
Thu, 15 April 2010 00:14  |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Stepano,
I have made small test with the electron in the 90 < theta < 100 (degree) range and 0.5 GeV to 1.5 GeV momentum.
PndPidCorrelator have been used and compared with generated one.
Different interaction region z=0 and z=5cm are tested and the results looks reasonable.
If interaction point is moved to z=5cm, 92-94 degree could not recontructed well, becuase of positioning of taget pipe and absent of barrel layer of MVD.
But I do not understand clearly on the general concept of tracking procedure with shifted interaction region.
As far as I understand, hits of every detectors are only important for the tracking.
If final vector components are pointed back to vertex position and the tracking is surely correct, then origin of tracks can correctly find, even though real vertex postion is moved to few cm. So, in some sense the tracking is independent from vertexing.
Is this statement also valid in LHEtracking task?
or do I have to consider some assumption of vertex position to z(0,0,0) in the tracking, specially in LHE?
Thanks,
Donghee
|
|
|
|
|
|
|
|
|
|
| Re: PndLhePidTrack [message #10540 is a reply to message #10537] |
Thu, 15 April 2010 13:03 |
Gianluigi Boca
Messages: 177
Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
| Tobias Stockmanns wrote on Thu, 15 April 2010 08:24 |
Hi Stefano and Donghee,
what about track finding? I thought that conformal mapping relies on tracks coming from the primary vertex.
Cheers,
Tobias
|
In the STT pattern recognition indeed there is the assumption that tracks come from 0,0,0 . This assumption is crucial for the algorithm to work. Indeed it works well as long as the interaction vertex is far from 0,0,0 a few mm. When the vertex is farther than 1 cm then problems arise (loss of efficiency and spurious hits inclusion).
Consequently. based on my experience, I would be (very) surprised if any pattern recognition algorithm using the conformal mapping in the XY plane, worked when the primary vertex is far 5 cm from the expected position.
That is also the reason why I have always claimed that as far as the Lambda is concerned we need to write a special pattern recognition package.
Gianluigi
|
|
|
|
| Re: PndLhePidTrack [message #10546 is a reply to message #10540] |
Sat, 17 April 2010 14:52 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Gianluigi Boca,
If your statement is correct, then every secondary vertex like K0, lambda, which have some decay length more than few cm, cannot reconstructed any more. That is quite pity, but I assume that is not implemented right now because of some ordering of priority in global tracking.
So, current tracking package is now only optimized at primary vertex.
You mentioned only about STT.
I am wondering how about rest of trackers.
What is the situation for stand alone track finding with TPC, MVD, MDT, and GEM?
If one of those do not find any track due to strong assumption of z=0, the efficiency of lhetrack would be automatically drop down, whatever rest of part are correctly contributed to build a true trajectory.
Best regards,
Donghee
|
|
|
|
| Re: PndLhePidTrack [message #10548 is a reply to message #10546] |
Sun, 18 April 2010 17:51 |
Gianluigi Boca
Messages: 177
Registered: March 2004
|
first-grade participant |
From: *gsi.de
|
|
| Donghee Kang wrote on Sat, 17 April 2010 14:52 |
Dear Gianluigi Boca,
If your statement is correct, then every secondary vertex like K0, lambda, which have some decay length more than few cm, cannot reconstructed any more. That is quite pity, but I assume that is not implemented right now because of some ordering of priority in global tracking.
So, current tracking package is now only optimized at primary vertex.
Best regards,
Donghee
|
Yes, in my opinion, for the Vees it is necessary to write a package that come after the 'normal' pattern recognition. That is true
for the STT, and my feeling is that could be true also for other detectors.
Only those hits not used by the 'normal' pattern recognition would need to be taken into account at this point. These hits should be searched for finding tracks not coming directly from 0,0,0.
Gianluigi
|
|
|
|
|
|
| Re: PndLhePidTrack [message #10582 is a reply to message #10551] |
Fri, 23 April 2010 11:59 |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi Stefano,
the resolution of the fit can not depend on the difference in start vertex (0,0,0) vs (4,4,4). Could you please investigate and/or explain the following points:
- why are there 764 tracks in the distribution for 4,4,4 and much less in the 0,0,0 distro?
- what is the theta range you used?
- Could you please check whether the number of hits in the track is reduced in the 4,4,4 case? It could explain the worse resolution in the fit. Maybe your pattern reco can not use all hits in the case?
Cheers, Christian
|
|
|
|
|
|
| Re: PndLhePidTrack [message #10585 is a reply to message #10583] |
Fri, 23 April 2010 13:55 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *dip.t-dialin.net
|
|
Dear Stepano and Christian,
Many of us is now pointing and understanding that the pattern recognition of track finding is strongly depends on the initial vertex position. If the primary vertex is moved to some way around from 0,0,0, then each detector part can not effectively find one of track.
Consequently, resolution would be drop down in the pid of lhetracking.
I cannot understand also, why are there 764 tracks in the distribution for 4,4,4 and much less in the 0,0,0 distro.
In my point of view tracking efficiency of (4,4,4) must be worser than (0,0,0).
I guess that it is not only related LHE tracking, but also the tracking of each single piece of every detector are strongly connected. One cannot simply introduce and modify something like an option for different position of interaction point for track finding in the lhetracking.
A single track from each detector must to be found with moved vertex at first, then global hits can be defined in the lhetracking efficiently. That's mean that one have to modify every detector part before building one track in lhetracking.
I think that is quite huge stuff.
My question is whether one can handle the interaction point directly in lhetracking or have to have some improvement of track finidng from every detector piece with moved point at first.
Best wishes,
Donghee
|
|
|
|
| Re: PndLhePidTrack [message #10592 is a reply to message #10585] |
Mon, 26 April 2010 17:05 |
donghee
Messages: 385
Registered: January 2009
Location: Germnay
|
first-grade participant |
From: *kph.uni-mainz.de
|
|
Dear Panda User,
I'm trying to understand how the LHE tracking works in very general and naive(?) view.
Hits of every detectors (MVD, TPC, GEM etc...) have been produced in MC+Digitization stage.
In LHE tracking, a hit maker use every hits from tpc, mvd, and gem to construct a global hit.
Upto this procedure, there is no assumption for interaction point 0,0,0 in my understanding.
Then the track finder try to build a track candidate with introducing track cuts, and a pattern recognition has been done in this stage.
And finally fitter perform track fitting for this candidate.
In principle, one can modify track finder to find shifted interaction point, if I correctly understand.
You don't need to care about full stuffs from all detector.
That's mean that one can directly extend tracking to secondary vertex and shifted vertex at lhetracking in very simple view.
I know that the real modification should be really really difficult.
If I'm wrongly understanding the lhetracking package, please correct me!
Thank you for your reading!
Donghee
[Updated on: Mon, 26 April 2010 17:07] Report message to a moderator |
|
|
|
| Re: PndLhePidTrack [message #10593 is a reply to message #10592] |
Mon, 26 April 2010 18:09 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
| Donghee Kang wrote on Mon, 26 April 2010 17:05 |
Then the track finder try to build a track candidate with introducing track cuts, and a pattern recognition has been done in this stage.
And finally fitter perform track fitting for this candidate.
In principle, one can modify track finder to find shifted interaction point, if I correctly understand.
You don't need to care about full stuffs from all detector.
That's mean that one can directly extend tracking to secondary vertex and shifted vertex at lhetracking in very simple view.
|
In theory what you say is correct: by applying some modifications, it is possible to use conformal mapping also for secondary verteces. One should improve the LheTrackFinding, and also the LheTrackFitting.
But, in order to do this, we should dig inside the code and try to find all the "guilty" points.
Feel free to check the code and to suggest some implementations that could help us on this side. Unfortunately, inside the "lhe developer group" (myself) there it not so much manpower to perform this kind of study and improvement.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Nov 30 20:24:55 CET 2024
Total time taken to generate the page: 0.00753 seconds
|
GSI Forum
Search
Help
Members
Login
Home
play mainly role in this stage. 
