Home » PANDA » PandaRoot » Tracking » plane id in track candidate
| plane id in track candidate [message #10254] |
Tue, 23 February 2010 10:23  |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi,
I have stumbled upon an interesting problem in track fitting:
If the pattern recognition determines that two hits in the same plane (e.g. MVD) belong to the same track, because a clear distinction is impossible, they are both input to the track fit. Then maybe the fit can determine which is the outlier or simply it has to use both. The question is how to handle that situation, i.e. how does the Kalman filter (or another algorithm) know that two hits are on the same plane. We could compare the complete plane parameters of both planes, but that is a big computational effort and hardly seems necessary. That is why I propose the following:
We should add an (unsigned) integer is called planeId to all hits in the track candidate. This way any tracking algorithm can easily determine if the next hit is in the same plane or in another one that requires an extrapolation.
If there are no objections, I will add the corresponding things to the PndTrackCand. The long term id behind this is that we will in the near future work on a tracking algorithm called "Deterministic Annealing Filter" (R. Fruehwirth, A. Strandlie, Track fitting with ambiguities and noise: a study of elastic tracking and nonlinear filters, Computer Physics Communications 120 (1999) 197–214) which has a dynamic weighting of hits in a fit, especially if there are several of them in the same plane. This will be cool for doing realistic pattern reco track fitting including the MVD & GEMs.
Cheers, Christian
|
|
|
|
|
|
|
|
| Re: plane id in track candidate [message #10258 is a reply to message #10256] |
Tue, 23 February 2010 10:53  |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi Stefano,
I described the problem of how the fitter is supposed to know whether the next hit is in the same plane as the last one. That is not reflected in your reply. What do you propose for this issue instead of what I just proposed? If I dont have this info, I might not be able to make the DAF work for PANDA, I guess...
Cheers, Christian
|
|
|
|
| Re: plane id in track candidate [message #10259 is a reply to message #10257] |
Tue, 23 February 2010 10:57 |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi Tobias,
I understand your point of putting the planeId into PndHit. However, I do not see, how that info is available when I do the fit. When I do the fit, I just base it on what is inside PndTrackCand. Do you see a way out of this.
About assigning the ID: The ids would not even have to be consistent from track to track. As long as the same plane carries the same id in the same TrackCand, it would be fine.
BTW, for hits which are not even in planar detectors (STT, TPC, ...) we could just use planeId==0, which will be compressed away on the disk by ROOT. So, this will not be a major issue.
Cheers, Christian
|
|
|
|
| Re: plane id in track candidate [message #10260 is a reply to message #10256] |
Tue, 23 February 2010 11:07 |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi,
I just had another idea: How about putting the plane ID into the detector ID unsigned int which we have anyway. We could reserve the least significant 8 bits for detector id, the next 8 bits for planeId, and the rest maybe for the future. That would make the least overhead.
Christian
|
|
|
|
|
|
| Re: plane id in track candidate [message #10262 is a reply to message #10261] |
Tue, 23 February 2010 11:45 |
|
Anonymous Poster
|
|
From: 89.204.153*
|
|
Hi,
you are right that I still need to access the hit info before fitting of course. But I just create the reco hits from the TClonesArrays, I dont look at more info. It is difficult to organize.
I would exactly call what I proposed a misuse of the detector ID....
Well then if there are only objection and no ideas on how to do it otherwise for the time being, I will not do it.
Christian
|
|
|
|
|
|
| Re: plane id in track candidate [message #10264 is a reply to message #10263] |
Tue, 23 February 2010 11:58 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi Lia,
that is how it was done so far, but I wanted to avoid all those operator== calls. And for the DAF I would need this information of which hits are in the same plane before i even call extrapolate.
Christian
|
|
|
|
| Re: plane id in track candidate [message #10265 is a reply to message #10258] |
Tue, 23 February 2010 12:04 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
| Christian Hoeppner wrote on Tue, 23 February 2010 10:53 |
Hi Stefano,
I described the problem of how the fitter is supposed to know whether the next hit is in the same plane as the last one. That is not reflected in your reply. What do you propose for this issue instead of what I just proposed?
|
I supposed my answer was clear, but maybe I have not stressed it enough. I try to explain it again:
| Stefano Spataro wrote on Tue, 23 February 2010 10:36 |
Hi,
I think the "two planes" problem is a problem of the finding, and not of the fitting.
|
The pattern recognition algorythm should take care about this issue, if it is problematic. How much is the number of tracks affected by this problem?. How much are the perfomances reduced for this kind of problem? Do you have a quantitative extimation? Just to understand if it is a second order problem or more urgent.
| Christian Hoeppner wrote |
If I dont have this info, I might not be able to make the DAF work for PANDA, I guess...
|
What do you mean by "DAF"?
|
|
|
|
|
|
| Re: plane id in track candidate [message #10267 is a reply to message #10265] |
Tue, 23 February 2010 12:28 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi,
the DAF is the Deterministic Annealing Filter I was quoting in my first message in this thread.
I dont know what the order of the problem is. It is a principle problem that pattern reco can never 100% decide only the right hit in a detector plane. I am trying to find a consistent way to treat this problem. It might or might not affect many tracks, however the problem is interesting and real. It will be very interesting to study what happens with realistic MVD pattern reco for instance with different pile-up or noise levels. I think especially pile-up will be an issue as the MVD does not have a zero interation time, I assume. How do different fitting algorithms (such as the DAF) make the situation better/worse, ..?..?.
Christian
|
|
|
|
|
|
| Re: plane id in track candidate [message #10271 is a reply to message #10270] |
Tue, 23 February 2010 15:41 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi Gianluigi,
what exactly do you propose as a strategy to reject outliers? Please remember that so far we do not have a smoother for our Kalman filter.
A request such as this seems reasonable, but I am not sure, it should be made to our group. There are two coordinators for tracking. We are not the only ones who can contribute to track fitting.
However, as I said we have such plans. But it is just a technical student on the task. So, there is no time estimate of guarantee that it will work. That is all the manpower we have for this in the moment.
Cheers, Christian
|
|
|
|
|
|
| Re: plane id in track candidate [message #10273 is a reply to message #10272] |
Tue, 23 February 2010 16:15 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi,
-- The strategy to reject the outliers could simply consist in the exclusion of a hit when it is too distant from the extrapolated trajectory to it.
That requires a good knowledge of the track parameters at any point. It requires a smoother which we currently dont have. Currently we only know the best estimates of the track parameters, including all hit information, at the first and last point. So currently it cant be done in a nice way.
Cheers, Christian
|
|
|
|
| Re: plane id in track candidate [message #10274 is a reply to message #10262] |
Tue, 23 February 2010 16:45 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Hi,
I would like to focus in this post on the detectorID issue, as it is so close to the discussion I started ~2 weeks ago about the fDetectorType.
Assuming that we will all agree that we need a fast information on the plane id then the fDetectorId member of the FairHit class is the most intuitive place to get this information from. We could reserve there several bits for detector id, plane id, straw tube id for STT/DCH, side and strip number for GEM digi, and so on.
In order to have also information about the data type, the last 4 bits could be reserved for it. This could be set to either MC track, MC point, digi, cluster, hit, local track, global track or whatever you like. Of course, when the fDetectorId for track is created, then plane or even detectorId are useless, but the spared bits could be used for something else.
To summarize, we would have a 32 bit int, which could be divided into:
5 bits for the detectorId (31 possibilities, excluding 0, should be enough, 14 defined in PndDetectorList)
5 bits for the planeId (any detector needs more?)
18 bits for any detector specific stuff
4 bits for the data type (MC track, MC point, digi, cluster, hit, local track, global track or track candidate, track)
I would not like to introduce another integer into existing data structure. I think we should try to use what is already available.
yours,
radek
|
|
|
|
| Re: plane id in track candidate [message #10275 is a reply to message #10274] |
Tue, 23 February 2010 16:48 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi Radek,
if the STT wants to use the 'planeId' to set the tube number, they would need more bits (I guess 16 bits).
I like your idea. Do you see anything speaking against transporting this info into the track candidate?
Cheers, Christian
|
|
|
|
| Re: plane id in track candidate [message #10276 is a reply to message #10275] |
Tue, 23 February 2010 17:06 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Well, it is very simple. One just add hits not with kGemHit, kSttHit, kMvdPixelHit, but with the hit->GetDetectorID(), and basing on this very number, or rather on the detector part of it, corresponding RecoHitFactory should be choosed. Therefore each added PndTrackCandHit will have different fHitId (equal to fDetectorId of the FairHit). But the decision on which RecoHitFactory to choose will base on part of this integer, a combination of the detectorId and dataType parts.
Is it possible to implement it like this?
yours,
radek
|
|
|
|
| Re: plane id in track candidate [message #10277 is a reply to message #10276] |
Tue, 23 February 2010 17:11 |
|
Anonymous Poster
|
|
From: *e18.physik.tu-muenchen.de
|
|
Hi,
yes this could be implemented. So to summarize, the detector ID in the trackCand would consist of a bit mask. Some part of this bit mask would be the kGemHit, kSttHit, kMvdPixelHit, ... which is used to produce hits in the RecoHitFactory. Could we do it a way that this kGemHit, kSttHit, kMvdPixelHit, ... info is in the least significant bits? That way it will be easiest for me.
Regards, Christian
|
|
|
|
|
|
| Re: plane id in track candidate [message #10279 is a reply to message #10277] |
Tue, 23 February 2010 17:59 |
StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
|
first-grade participant |
From: *to.infn.it
|
|
Excuse me,
maybe I have missed some part of the discussion,
but, if I have understood well, this fPlaneId is already contained inside the data object (FairHit->GetDetectorId()), and the trackcand is just the link between the track and each hit of the track.
Then, why you want to propagate an information already existing in the hit inside the track cand? From the trackcand one can retieve the detector id and then compute plane id and so on. It is not clear to me why we should copy this number another time, and invent a new mask scheem, inside the track candidate.
Maybe the answer is in some message of the thread, but I was not able to find exactly the reason. Could you please short comment about, just to have a better idea?
|
|
|
|
| Re: plane id in track candidate [message #10280 is a reply to message #10277] |
Tue, 23 February 2010 18:00 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
In fact, I would like to get rid of this kGemHit, kSttHit, kMvdPixelHit, and to replace it with something else. I would prefer PndDetectorList.h to look like:
enum DetectorId {
kDCH,kDRC,kDSK,kEMC,kGEM,kLUMI,kMDT,kMVD,kRPC,kSTT,kTPC,kTOF,kHYPG,kHYP} ;
enum DataType {
kUnknown, kMCTrack, kMCPoint, kDigi, kCluster, kHit, kTrackCand, kTrack};
enum SensorSide { kTOP, kBOTTOM };
Now, if one creates for example a point in GEM station3, front side, I would set
fDetectorId to:
fDetectorId = kMCPoint << 27 | kGEM << 22 | 3 << 17 | kTOP << 16;
or something like this depending on the number of bits reserved.
Digi created from this point would have fDetectorId:
fDetectorId = kDigi << 27 | kGEM << 22 | 3 << 17 | kTOP << 16 | digiNr;
Hit created from this point would have fDetectorId:
fDetectorId = kHit << 27 | kGEM << 22 | 3 << 17 | kTOP << 16;
If I create hit factory for GEMhits, I would give there the number kGEM<<5 | kHit,
and choose for the factory only hits having correct bits in detector and data places.
As for which side of the fDetectorId to use, I would nevertheless prefer to use the most significant bits for more general information, so first datatype, then detectortype, planeid, side, and whatever.
BTW, I just talked to Gianluigi about the STT, and for STT I would record information about the planeID (defined as the straw layer number, starting from the closest to the beam pipe, looking at the STT picture provided by Gianluigi, there are 28 layers at most, and so 5 bits is just enough), sectorID (which is simply the sextant number, 3 bits), strawID (id of the straw in a layer 6 bits).
So a MC point in STT:
fDetectorId = kMCPoint << 27 | kSTT << 22 | layerID << 17 | sectorID << 14 | strawID << 8;
I hope it satisfies STT:)
For MVD it would mean, there should be two data types: kMVDStrip and kMVDPixel.
And so on also for different detectors. This way the information is highly structurized, and from this one integer one can get information about the data type, detector and plane ids.
Exactly this integer fDetectorId would be stored in PndTrackCandHit.
yours,
radek
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: plane id in track candidate [message #10289 is a reply to message #10287] |
Wed, 24 February 2010 09:59 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear Tobias,
I never said I want to store information about planeId in the PndTrackCand. I meant that for this we should use the fDetId member of the PndTrackCandHit class. There would be no changes to the PndTrack{,Cand,CandHit}.{h,cxx} classes AT ALL.
Another issue is the MC propagation. The information that used to be coded in the fDetectorId is still there, only coded at some bits of the Int_t. To retrieve this information is trivial - as Christian agrees - and the bit shift operations are virtually costless.
You expressed concern also about the misuse of the scheme proposed by me and possibility of creating MVD Bumps. Well, it is always possible and you even now you cannot avoid users using integers out of the the enum fDetectorType of PndDetectorList.h.
Anyways, as I see my idea was generally disliked, so we still have to think a bit more about this problem.
Yours,
radek
|
|
|
|
| Re: plane id in track candidate [message #10290 is a reply to message #10280] |
Wed, 24 February 2010 12:47 |
Lia Lavezzi
Messages: 291
Registered: May 2007
Location: Torino
|
first-grade participant |
From: *pv.infn.it
|
|
Hi,
sorry, maybe the discussion has already moved to a different topic (I just read quickly the last messages), and this remark is not usefull anymore, but let me just specify a thing on the tubeID of the STT.
| Quote: |
BTW, I just talked to Gianluigi about the STT, and for STT I would record information about the planeID (defined as the straw layer number, starting from the closest to the beam pipe, looking at the STT picture provided by Gianluigi, there are 28 layers at most, and so 5 bits is just enough), sectorID (which is simply the sextant number, 3 bits), strawID (id of the straw in a layer 6 bits).
So a MC point in STT:
fDetectorId = kMCPoint << 27 | kSTT << 22 | layerID << 17 | sectorID << 14 | strawID << 8;
I hope it satisfies STT:)
|
I am implementing a map of the tubes (I don' t remember if I already told about this, but it is one of the workpackages) and in it I assigned the tubeID with the same numbering scheme of the stt geo files: each tube has a different number, from 0 to about 5000.
I would really prefer (if possible) to keep this numbering scheme and use only the strawID (or tubeID), so 13 bits, unless there is some particular reason to change it, because in this way the macro for tube positioning and the geo files will all have the same numbering scheme.
Thank you,
Lia.
|
|
|
|
Goto Forum:
Current Time: Sun Dec 22 07:20:25 CET 2024
Total time taken to generate the page: 0.00955 seconds
|
GSI Forum
Search
Help
Members
Login
Home
