GSI Forum
GSI Helmholtzzentrum für Schwerionenforschung

Home » PANDA » PandaRoot » Tracking » [FIXED] Bug in PndFts/SttMvdGemTrackingIdeal ?
icon9.gif  [FIXED] Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15504] Wed, 18 September 2013 23:10 Go to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 2.235.190*
Hi tracking guys,
I see a potential bug, or maybe a feature, of the ideal track finders, i.e. PndFtsTrackerIdeal and PndSttMvdGemTrackingIdeal.

If I check PndFtsTrackerIdeal, first it search for FTS hits in the event:

if(fHits[0]->GetEntriesFast() == 0) {
  return;


If there are FTS hits, it start to fill the PndtrackCand with hits from MVD, GEM and FTS.
If there are at least 3 hits:

if( tcand->GetNHits() < 3 ) continue;


then the candidate is stored.

The main problem that I see is that there is no requirement that in the trackcand there is at least a FTS hit. For single particle events it is the same. But if you have a 2-particle events, one particle in the forward part and another in the barrel, the code will see that there are FTS hits in the event, and it will fill not only the trackcand of the fwd track, but it will create also a trackcand with the MVD+GEM hits of the barrel particle. Such second track is not a forward track. The opposite in the case of the PndSttMvdGemTrackingIdeal.

This means that maybe, once you run a barrel and a forward tracker together (both ideal, or one ideal and another real), you could have in the same event a track with MVD+STT+GEM hits, and another track with the same hits from MVD+GEM but w/o STT, since it is a "forward" track. The same track is reconstructed twice.

I hope I was clear. Maybe it would be better to put a selection, so that only TrackCand with at least one FTS or STT hit are stored. Maybe it would be good also to increase such number, since tracking with a single hit straw is impossible I believe.

Please let me know your opinions, maybe I read wrongly the code.


[Updated on: Wed, 10 September 2014 14:49]

Report message to a moderator

Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15505 is a reply to message #15504] Wed, 18 September 2013 23:37 Go to previous messageGo to next message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *dip0.t-ipconnect.de
Hello Stefano,

I have just looked at PndFtsTrackerIdeal and I do believe that you are right in what you describe. I furthermore believe that it is a bug and I would like to suggest to only write out tracks which have at least 5 hits in the dipole field region of the FTS (as otherwise a reconstruction of the particle's momentum is extremely hard). I will work on the modification for PndFtsTrackerIdeal. However, it might take me some time as I am at a PWA School until Friday next week with a tight program and I only have a netbook with me.

Best wishes,
Martin
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15507 is a reply to message #15505] Thu, 19 September 2013 14:23 Go to previous messageGo to next message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *dip0.t-ipconnect.de
Hello Stefano,

I wanted to start fixing the problem during today's lunch break, but I noticed that we might not have the described problem after all. (Sorry, I was quite tired when I looked through the code last night.) I looked at the following code excerpt from
void PndFtsTrackerIdeal::Exec(Option_t * option):

(Note that iDet == 0 corresponds to the FTS)

// Detector loop
  for(Int_t iDet=0;iDet<4;iDet++){
    if (kFALSE == fBranchActive[iDet]) continue; //skip manually switched off detector
    if(fVerbose>4) Info("Exec","Use detector %i",iDet);
    // Hit loop
    for (Int_t ih = 0; ih < fHits[iDet]->GetEntriesFast(); ih++) {
      ghit = (FairHit*) fHits[iDet]->At(ih);
      if(!ghit) {
        if(fVerbose>3) Error("Exec","Have no ghit %i, array size: %i",ih,fHits[iDet]->GetEntriesFast());
        continue;
      }
      Int_t mchitid=ghit->GetRefIndex();
      if(mchitid<0) {
        if(fVerbose>3) Error("Exec","Have a negative mcHit %i",mchitid);
        continue;
      }
      myPoint = (FairMCPoint*)(fMCPoints[iDet]->At(mchitid));
      if(!myPoint) continue;
      Int_t trackID = myPoint->GetTrackID();
      if(trackID<0) continue;
      
      if(fVerbose>5) Info("Exec","Have a Hit %i at Track index %i",ih,trackID);

      // Continue Construction of a track candidate (start with FTS hits)
      // Track candidates and corresponding MC track index are saved in a map
      PndTrackCand* cand=candlist[trackID];
      if(NULL==cand){
        if(0!=iDet){
          if(fVerbose>5) Info("Exec","Skip Hit %i, it's not connected to a Track in FTS",ih);
          continue; // skip Tracks in MVD/GEM not going to FTS
        }
        if(fVerbose>5) Info("Exec","Create new PndTrack object %i",trackID);
        cand=new PndTrackCand();
        cand->setMcTrackId(trackID);
        if(fVerbose>5) Info("Exec","Creating new PndTrack object finished %i",trackID);
      }
      if(fVerbose>5) Info("Exec","add the hit %i to trackcand %i",ih,trackID);
      cand->AddHit(fBranchIDs[iDet],ih,myPoint->GetTime());
      // Figure out if the current hit is the earliest in the event
      if(!firstHit[trackID] || firstPoint[trackID]->GetTime() > myPoint->GetTime()) {
        firstHit[trackID]=ghit;
        firstPoint[trackID]=myPoint;
      }
      // or the latest one
      if(!lastHit[trackID] || lastPoint[trackID]->GetTime() < myPoint->GetTime()) {
        lastHit[trackID]=ghit;
        lastPoint[trackID]=myPoint;
      }
      
      candlist[trackID] = cand; // set
    }// end loop over hits
  }// end loop over detectors
  // now we have track candidates




The most important part is actually this one:

PndTrackCand* cand=candlist[trackID];
      if(NULL==cand){
        if(0!=iDet){
          if(fVerbose>5) Info("Exec","Skip Hit %i, it's not connected to a Track in FTS",ih);
          continue; // skip Tracks in MVD/GEM not going to FTS
        }
        if(fVerbose>5) Info("Exec","Create new PndTrack object %i",trackID);
        cand=new PndTrackCand();
        cand->setMcTrackId(trackID);
        if(fVerbose>5) Info("Exec","Creating new PndTrack object finished %i",trackID);
      }


So we first look at all FTS Hits individually and later all hits from other detectors in the event. For each hit we figure out which MC track caused them. ONLY if there is at least one FTS (iDet == 0) Hit from a MC track, we create a PndTrackCand. If there was no FTS hit for a MC track (iDet != 0), then the algorithm fails to load the corresponding PndTrackCand and it continues (meaning it skips the hit).

So, I believe that the PndFtsTrackerIdeal does exactly what you suggested (write out PndTrackCands which have at least 1 FTS Hit). I would nevertheless like to change that behavior so that it requires at least 5 FTS hits in order to be more realisitic and if no one objects I will change the algorithm accordingly in the next few lunch breaks / nights.
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15508 is a reply to message #15507] Thu, 19 September 2013 17:24 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
I got the point, then it seems correct.
Maybe it would be good also to exclude, in low momentum particles, the tracks bent by the dipole and going forward again, since they create strange artifacts maybe not easy to fit, impossible to reconstruct I believe.
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15510 is a reply to message #15507] Thu, 19 September 2013 17:37 Go to previous messageGo to next message
Tobias Stockmanns is currently offline  Tobias Stockmanns
Messages: 489
Registered: May 2007
first-grade participant
From: *ikp.kfa-juelich.de
I still wonder why the FairLinks are not used for this purpose. They would allow to solve this problem in a much more elegant way and this task is exactly what they are build for.

Cheers,

Tobias
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15511 is a reply to message #15510] Thu, 19 September 2013 17:43 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 94.161.36*
The task was written in 2011 by Ralf for the MVD tdr, when FairLinks were still fighting against tpc clusters and memory. It would be good an update of the task using the links, I agree.
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15512 is a reply to message #15508] Thu, 19 September 2013 18:42 Go to previous messageGo to next message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *dip0.t-ipconnect.de
Stefano Spataro wrote on Thu, 19 September 2013 17:24


Maybe it would be good also to exclude, in low momentum particles, the tracks bent by the dipole and going forward again, since they create strange artifacts maybe not easy to fit, impossible to reconstruct I believe.


Hello Stefano,

do you mean by that tracks which are bent in the dipole so much that they turn around and fly towards the barrel again (and therefore leave additional hits in the FTS)? If these events cause problems with the fitter, I will remove such tracks at the end of the loop on FTS hits. I plan to check all (MC truth) time-ordered FTS hits associated to a given PndTrackCand and check if the z-component is increasing. If not, I will remove the PndTrackCand.


Tobias Stockmanns wrote on Thu, 19 September 2013 17:37

I still wonder why the FairLinks are not used for this purpose. They would allow to solve this problem in a much more elegant way and this task is exactly what they are build for.



Hello Tobias,

I will try to move the implementation of PndFtsTrackerIdeal to FairLinks. Can you recommend a task which I can use as an example? Is it a good idea to start looking at PndTrackingQualityAnalysis?

Kind regards,
Martin
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15513 is a reply to message #15512] Thu, 19 September 2013 19:25 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: 2.235.190*
Martin J Galuska wrote on Thu, 19 September 2013 18:42

Hello Stefano,

do you mean by that tracks which are bent in the dipole so much that they turn around and fly towards the barrel again (and therefore leave additional hits in the FTS)? If these events cause problems with the fitter, I will remove such tracks at the end of the loop on FTS hits. I plan to check all (MC truth) time-ordered FTS hits associated to a given PndTrackCand and check if the z-component is increasing. If not, I will remove the PndTrackCand.


Exactly. But also inside the dipole, they could hit the same layer twice, once in the forward direction and once in the backward direction. Maybe some algorithm could be able to find circles in the dipole, but I believe it will be quite tough to reconstruct the backward segment in FTS1 and 2. Of course this Moreover, sometimes you have secondaries starting inside the diopole region, with the first hit in fts 34. Such tracks will be impossible tor econstruct. Then maybe one should ask to have at least a minimum number of fired FTS12 straws, and a minimum for FTS34.
Let's put in this way:i believe we should clean a bit the ideal track sample, to select only tracks that the real algorithm will be able to reconstruct.If we leave them, our efficiency will be spoiled to a too high value compared to real case.

My humble opinion, comments and suggestions are welcome.
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15518 is a reply to message #15513] Fri, 20 September 2013 18:51 Go to previous messageGo to next message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *dip0.t-ipconnect.de
Hello Stefano and other collaborators,

I have just uploaded an updated version of PndFtsTrackerIdeal which is supposed to get rid off tracks that turn around in the forward dipole field and it also should not write find any tracks which have less than 5 hits in the FTS.

I write "should" because I currently do not have time to check it thoroughly, but the code compiles. I hope someone will want to run some simulation and check if the desired behavior is achieved.

I am also open to suggestions for improvements and I will certainly work on the rewrite using FairLinks.

Kind regards,
Martin
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15898 is a reply to message #15518] Mon, 24 February 2014 16:18 Go to previous messageGo to next message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *physik.uni-giessen.de
Dear all,

after having changed the standard behavior of the FTS ideal tracking to make it behave more realistically from the FTS tracking point of view, Donghee noticed a problem in the tracking efficiency in the theta range 5⁰ to 12⁰ or so.

I required a track to be found by the FTS tracking to have at least 5 FTS hits. Previously, the FTS ideal tracker "found" all tracks that had at least 1 hit in the FTS.

As I said, from the FTS tracking point of view that behavior is more realisitic. However, currently there is only a tracking starting from STT + MVD and from FTS in the code. Both tracking algorithms find mostly distinct sets of tracks so that a merge is easily done. Hits from GEM are only added to tracks found by FTS and by STT + MVD, but there is no tracking starting from GEM being used in the current version of the code.

As a workaround I implemented PndFtsTrackerIdeal::SetMinFtsHitsPerTrack(int); to set the number back to 1 to have an overall detector performance that is similar to before the changes in the FTS ideal tracking. I have just changed the default value to 1 to avoid possible problems and confusion, especially when the simulation campaigns will be executed and new results will be compared with old ones.

At this point I suggest to use the value of 5 for standalone performance studies of the FTS only.

Here is how:
PndFtsTrackerIdeal* trackFts = new PndFtsTrackerIdeal();
  trackFts->SetMinFtsHitsPerTrack(1);
  trackFts->SetRelativeMomentumSmearing(0.05);
  trackFts->SetVertexSmearing(0.05, 0.05, 0.05);
  trackFts->SetTrackingEfficiency(1.);
  trackFts->SetTrackOutput("FtsIdealTrack");
  trackFts->SetPersistence(kFALSE);
  fRun->AddTask(trackFts);


Kind regards,
Martin
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15922 is a reply to message #15898] Wed, 05 March 2014 16:14 Go to previous messageGo to next message
StefanoSpataro is currently offline  StefanoSpataro
Messages: 2736
Registered: June 2005
Location: Torino
first-grade participant

From: *to.infn.it
Hi,
I think the value 5 is the more correct, since this is tracking for FTS detector.
Tracking with only MVD+GEM is not present in the default reconstruction, but it is not a task of that track finder.
Re: Bug in PndFts/SttMvdGemTrackingIdeal ? [message #15932 is a reply to message #15922] Fri, 07 March 2014 17:35 Go to previous message
MartinJGaluska is currently offline  MartinJGaluska
Messages: 203
Registered: March 2010
Location: Germany
first-grade participant
From: *physik.uni-giessen.de
After a discussion with Stefano about this issue, the decision was made that the standard behavior should be to require a minimum of 5 FTS hits.

If necessary, users can change this number as explained in an earlier post.
Previous Topic: Tracking efficiency release/jan14
Next Topic: Central Tracker performances with reduced B field
Goto Forum:
  


Current Time: Wed Dec 04 00:48:57 CET 2024

Total time taken to generate the page: 0.00922 seconds