GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Tracking » Global Problems
Re: Global Problems [message #10076 is a reply to message #10072] Wed, 03 February 2010 11:49 Go to previous messageGo to previous message
Radoslaw Karabowicz is currently offline  Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
continuous participant
From: *gsi.de
Thank you all for the quick comments. It will be best to discuss the whole PndDetectorList issue on the next evo meeting.

Quote:

here is what was discussed and decided:

http://panda-wiki.gsi.de/cgi-bin/view/Computing/Minutes05Aug2008

see "detector type"

http://panda-wiki.gsi.de/cgi-bin/view/Computing/PandaRootTrackModel

see "Flags".

cheers, Soeren


I think that a lot of people are unaware of the two memos you quoted in your answer. Could we put both links in the PndDetectorList.h file as comments? Thus anyone opening the file would have links to what should really be here. Actually the link to the discussion on the next evo meeting should also come here.

To Stefano:
Quote:

About the fDetectorType, the current structure is mandatory for lhe tracking (I think it was originally taken from there) and for the reco hit factories of the kalman task. It is not clear to me which are the problems appearing now with the current code. That enum had to say from which TClonesArray one has to take the detector hits, this is the original meaning of the enum. I think the Tobias' addenda are not harming at all, and they are still following the original idea of TCA/data object.

My biggest problem was that the STT hits used number "3" as the detector/point/hit identifier and TPC uses kTpcCluster for Cluster identifier, which happens to be also equal to "3".

Looking into PndDetectorList.h I was not sure what is the goal of the fDetectorType enum. There are two values for GEM that I did not use, 7 for MVD, 3 for STT that were not used, no values for DCH. I think we should make order and decide what should be there.

Ordering parameter

The last issue is that of the ordering parameter. I agree that the distance from point (0,0,0) makes most sense as the ordering parameter for the hits. The only problem that for some detectors (or rather for the strip detectors) this value is not easy to get. The proposition to use radius as the ordering parameter for the STT detector may and does create problems:

TrackCand no. 1 has 13 hits.
[ ihit | detid | index ]
[ 0 | 10 | 0 ]
[ 1 | 10 | 1 ]
[ 2 | 10 | 2 ]
[ 3 | 3 | 0 ]
[ 4 | 3 | 1 ]
[ 5 | 10 | 3 ]
[ 6 | 3 | 2 ]
[ 7 | 18 | 0 ]
[ 8 | 18 | 1 ]
[ 9 | 18 | 2 ]
[ 10 | 18 | 3 ]
[ 11 | 18 | 4 ]
[ 12 | 18 | 5 ]


This is the second track of the first event, so it does happen rather often. Here the second number is the detectorID (10->MVD Pixel, 3->STT, 18->GEM). Naturally one would expect all the MVD hits before STT hits.

greetings,
radek
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Restructuring of Tracking Code
Next Topic: Genfit Reco Hits
Goto Forum:
  


Current Time: Fri Mar 29 16:21:14 CET 2024

Total time taken to generate the page: 0.00956 seconds