Home » PANDA » PandaRoot » Tracking » Global Problems
| Global Problems [message #10070] |
Tue, 02 February 2010 17:50  |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear developers,
As some of you know, in the last month I focused on writing the IdealTrackMerger, that would merge ideal PndTrackCand from different detectors into global tracks, that would then be fitted. The fit would take into account all the hits belonging to one track from different detectors.
I have however got to a point from which I cannot get out without your help. Mainly due to the reason that it concerns also your code. And also because I have not taken part in the discussion about the PndDetectorList from the beginning.
To cut the long story short. We are creating PndTrackCand for different detectors, and put there hits with ptrackcand->AddHit(detectorID,hitID,orderingParameter);
So far, so good.
But what is the detectorID?
I have used the DetectorId enum from the PndDetectorList.h.
The STT is constantly using fVolumeID = 3 (set in the PndStt.cxx).
DCH also uses hardcoded info (1).
On the other hand, MVD and TPC guys are using the fDetectorType enum (9 pixelMvd, 10 stripMvd, 3 tpcluster).
I have also seen that in the meantime the fDetectorType enum grew to contain information about the detector hit type, like point, digi, cluster or hit. I do not know if that was the goal from the beginning, but will follow the idea for GEM and DCH.
Do you have any other idea? And was the plan when creating both enums.
For example, if the MC point is created and added to stack, it is given DetectorId, mostly from DetectorId enum. Why not use for example kSttPoint from fDetectorType? And if we do not use this, then why to have it at all in the fDetectorType?
I hope that this message will trigger the discussion on the subject.
Ordering parameter?
Here the situation is slightly worse. When talking about the global track merger during the last collaboration meeting in Darmstadt, we have decided to use the distance from the target as the ordering parameter. This works fine for MVD, TPC and GEM. But in case of STT and DCH is very hard to get. When updating the DCH code, I've used the mcPoint->GetLength() which is the distance the particle travelled since its creation point. It was fine, because I used ideal hit producer and ideal tracking. The STT is using radius as the ordering parameter.
Therefore I would propose that we decide now on which parameter should be used as ordering parameter in all ideal track finders of various PANDA detectors.
Does the ordering parameter have to be the same as in the realistic track finder?
I think it does not have to be the same, but should be rather similar.
The track parameters that would serve best for the purpose are the fLength or fTime members of the FairMCPoint.h
My proposition is to use the fLength as the ordering parameter in various ideal track finders, as it is the one easier accessible in the realistic track finders.
Sorry for the long message and lots of reading and greetings from snowy GSI.
Sincerely yours,
radek
|
|
|
|
Current Time: Sat Apr 20 10:58:59 CEST 2024
Total time taken to generate the page: 0.00987 seconds
|
GSI Forum
Search
Help
Members
Login
Home
