Home » PANDA » PandaRoot » Tracking » alternative to LHE tracking
| alternative to LHE tracking [message #11338] |
Fri, 17 December 2010 11:59  |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear All,
In the last few months I have developed a track finder that is using most of the tracking detectors to form global tracks. The task is called PndBarrelTrackFinder, and is located in trunk/global directory. At present it uses MVD, STT, TPC and GEM hits, although the TPC option was not tested yet. I have also developed a QA task which should test the performance of the track finder. It produces several histograms in the output file that show the tracking efficiency, resolution, and number of detector hits in reconstructed tracks as a function of theta.
Few of them are presented below:
You can try yourself the task with macro/global/sim_BARREL.C and macro/global/digi_BARREL.C macros. To run, you should type:
root -l -q 'sim_BARREL.C(100)'
and
root -l -q 'digi_BARREL.C(100,22)'
The output file: digi_22Part_n100_BTF.root will contain reconstructed tracks in BarrelTrack and BarrelTrackCand branches of cbmsim tree, and QA histograms in BarrelTrackFinderQA directory.
Please test it and report any bugs.
Sincerely yours,
radek
|
|
|
|
|
|
| Re: alternative to LHE tracking [message #11344 is a reply to message #11339] |
Fri, 17 December 2010 15:49  |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear Stefano and All,
I am not sure how to describe the tracking shortly. The track model is a helix, that is a circle in x-y plane plus some pitch along the z-axis. Since this assumes the constant magnetic field parallel to z, the tracking will not work in the Forward Detector, and is not doing very well in the GEM region. Of course some future extensions are possible.
The main part of the program is the loop over hits. The hits in one event are mixed so that there is no correlation possible to MC.
Inside the loop the hit is matched to already found tracks. If it doesn't match to any track, the hit is being combined with previously unused hits to form tracks. If no such combination is possible, it is put in unused hit array.
The hit to hit matching assumes the track is primary, that is one of the 3 needed points to construct a circle in x-y plane is set to origin. The other two points (or circles for STT) are set to (x,y) parameters of the hits. In case of hits in MVD, TPC or GEM, where there is no ambiguity, only one circle is fit to 2 hits. With one STT hit there are two circles found (one including, one excluding STT hit, both tangent to it). With two STT hits there are 4 combinations. All the combinations are stored in the track.
The hit matches to already found track, if its distance to any of the track circles in x-y plane is smaller than some parameter (for now around 1mm, but should depend on hit resolution). If the hit matches to the track, then circles with all other track hits are formed. If other track hits are close enough to the circle, then the circle parameters are stored in the track.
After the track contains more than 3 hits and a lot of possible circle parameters from various hit combinations I try to see if there exists one common circle that would fit all the hits. If such mean circle exists, the criterium to attach next hits will be their proximity to this mean circle.
In fact only after this mean circle is found do I try to attach SKEWED STT hits to the track. When I attach them no new information about the circle in xy plane is obtained, only the pure information about z position of the place where skewed stt tube is tangent to the track circle... If there are enough hits in the track (presently more than 3) that carry the z information then I try to obtain the pitch of the track's helix. Again by checking if there is some mean helix pitch from which all the track hits are not too far.
After the main hit loop is finished, I loop over found tracks and get rid of the tracks that had no mean circle nor mean pitch found. They are usually short tracks formed from hits belonging to different MC tracks. This getting rid of tracks consist of moving track hits into the unused hits array, and removing the track from the list.
The last step is to attach the hits from the unused hits array to existing tracks.
The algorithm may be summarized by following simplified C++ code:
nofHits = fHitArray->GetEntriesFast();
nofTracks = 0;
nofUnusedHits = 0;
for ( ihit = 0 ; ihit < nofHits ; ihit++ ) {
Bool_t hitUsed = kFALSE;
for ( itr = 0 ; itr < nofTracks ; itr++ )
if ( MatchHitToTrack(ihit,itr) ) hitUsed = kTRUE;
if ( hitUsed ) continue;
for ( iuh = 0 ; iuh < nofUnusedHits ; iuh++ )
if ( HitMatchesToHit(ihit,iuh) ) hitUsed = kTRUE;
if ( hitUsed ) continue;
AddHitToUnusedHits(ihit)
}
RemoveShortTracks();
for ( iuh = 0 ; iuh < nofUnusedHits ; iuh++ )
for ( itr = 0 ; itr < nofTracks ; itr++ )
MatchHitToTrack(iuh,itr);
WriteTracks();
The tracks are written to the output tree as PndTrack (BarrelTrack) and PndTrackCand (BarrelTrackCand). The last difficulty is to retrieve the momentum information of the track from the helix parameters. For the time, there is some hardcoded values used to make the transformation.
If the explanation is not satisfactory, messy or unclear, please let me know.
yours,
radek
|
|
|
|
|
|
| Re: alternative to LHE tracking [message #11347 is a reply to message #11345] |
Sat, 18 December 2010 19:48 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *adsl.alicedsl.de
|
|
Dear Stefano,
I am showing the values as they come after the PndBarrelTrackFinder. I did not yet try the Kalman. From what I remember for the genfit one needs to provide space points, and for the STT I am not creating the PndSttHelixHits, but use the "original" PndSttHits. If my assumption is wrong, please correct it.
As for the definition of efficiency. It is always a problem and I have always saw it problematic. In the PndBarrelTrackFinderQA the efficiency is defined as a ratio of foundTracks to simulatedTracks as a function of MC momentum, theta or phi angles. In the denominator there are all the MC tracks (primaries and secondaries) that had at least 2 hits in MVD, STT, TPC and GEM (the sum counts) - at this very moment I don't know how was it possible for me to set the limit so low, it should be at 4 hits at least. The criterion for calling a track: foundTrack is based purely on momentum comparison. Presently there are no any hits comparisons (which should in fact be done). The reconstructed momentum matches MC momentum, when all three following conditions are satisfied:
- abs(mcMom.Mag-recoMom.Mag) < 0.1*mcMom;
- abs(mcMom.Phi-recoMom.Phi) < 1.5; // in degress, not rads
- abs(mcMom.Theta-recoMom.Theta) < 1.5; // in degress, not rads
In fact I just saw that in the PndBarrelTrackFinderQA there is a bug, and I am not checking for the theta angle... oops. Luckily a quick check and rerun confirms the results I've already presented. I will commit the fix on Monday.
yours,
radek
|
|
|
|
| Re: alternative to LHE tracking [message #11348 is a reply to message #11347] |
Sat, 18 December 2010 19:57 |
|
Anonymous Poster
|
|
From: *adsl.alicedsl.de
|
|
Hi Radek,
your assumption that GENFIT needs space point hits is not correct. The STT hits are fitted with the wire position and the drift distance to the wire since a long time. Can an STT expert maybe point out the corresponding reco hit class for Radek?
Cheers, Christian
|
|
|
|
|
|
|
|
| Re: alternative to LHE tracking [message #11376 is a reply to message #11348] |
Tue, 21 December 2010 14:56 |
Radoslaw Karabowicz
Messages: 108
Registered: June 2004
Location: GSI
|
continuous participant |
From: *gsi.de
|
|
Dear All, you are absolutely right. I have tested it yesterday, and the track fitting with Kalman/genfit works good, but slow:(.
Anyways, I have spotted and fixed two bugs:
- theta comparison now is taken into account when calculating efficiency
- particle charge is now correctly associated to track
I have also created histograms showing momentum resolution as functions of momentum magnitude, phi and theta. The first two dependences look rather OK, but for the smallest theta angles (in the region of GEM) the reconstructed momentum is... well, ugly.
The following plot base on the momentum as taken after the track finder, without fit.
The histograms are 2D, with X axis being the momentum, phi or theta, and Y axis being the momentum resolution. The histogram is then sliced and to each slice a gaussian function is fitted. The sigma of the fit is plotted as the black curve.
The simple change of the macro to include the genfitter:
FairGeane *Geane = new FairGeane();
fRun->AddTask(Geane);
PndRecoKalmanTask* recoKalman = new PndRecoKalmanTask();
recoKalman->SetTrackInBranchName("BarrelTrack");
recoKalman->SetTrackOutBranchName("BarrelFitTrack");
fRun->AddTask(recoKalman);
Works and fits the tracks. Below is the histogram showing the reconstructed momentum after PndBarrelTrackFinder (black curve) and after the fit applied (red curve). In this particular case 2 GeV muons were simulated.
yours
radek
|
|
|
|
Goto Forum:
Current Time: Fri Apr 19 13:44:15 CEST 2024
Total time taken to generate the page: 0.00923 seconds
|
GSI Forum
Search
Help
Members
Login
Home
