Bug in BrDigitizeTof::Event => New BRAT.

From: Jens Ivar Jordre (jensivar.jordre@fi.uib.no)
Date: Fri Aug 22 2003 - 13:29:46 EDT

  • Next message: Flemming Videbaek: "Re: Bug in BrDigitizeTof::Event => New BRAT."
    Howdy.
    
    I've found what I believe is a serious TOF digitization bug in
    BrDigitizeTof::Event, and one should gauge our previous TOF
    digitizations and analyses depending on them.
    
    To put it short, there is, as far as I can see, a mismatch between slats 
    and GEANT hits. To explain the bug I have done some cut and paste into 
    the function, listed here below:
    
    <snip>
    
    for(int is = 0; is < noslats; is++)
    {
    ...
       for(ih = 0; ih < NumHits; ih++)
         {
           ghit_p = (BrGeantHit*) GeantHits->At(ih);
    ...
           if (slat == is)
    	if(ghit_p->Dedx() > 0.0)
    	  {
    	    if(DebugLevel() > 1)
    	      cout << "Add slat " << slat+1 << " i.e. Isub = "
    		   << ghit_p->Isub()
    		   << " for " << GetName() << endl;
    	    slattable[slat]++;
    	    hit_p = ghit_p;
    	    hittable[hitno] = hit_p;
    	    hitno++;
    	  }
         }
       //
       // Single hit
       //
       if(DebugLevel() > 3)
         cout << "Slattable " << slattable[is] << endl;
    	
       if(slattable[is] == 1)
         {
           digtof_p = new BrTofDig();
           DigitizedTof->Add(digtof_p);
           digtof_p->SetSlatno(is+1);
           //  if (!tfp) // for mrs tofw
           // 		digtof_p->SetSlatno(is + panel*noslats + 1);
    	
           hit_p = hittable[0];
    ...	
         }
       //
       //  Multiple hits on same slat
       //
       else if(slattable[is] > 1)
         {
    ...
           //
           // Find the first time for the up and down Tube.
           //
           tup = tdown = 9999.0;
           for(n = 0; n < nlookup; n++)
    	{
    	  hit_p = hittable[n];
    ...
    	}
    ...
           for(n=0;n<nlookup;n++)
    	{
    	  hit_p = hittable[n];
    ...
    	}
    ...
         }
    }
    
    </snip>
    
    In the first nested loop (above the "Single hit" comment) GEANT hits
    matching the current slat number are stored (by pointer) in the hittable
    array, and the number of found hits is incremented.
    
    Looking in the signe hit section the selected hit used is _always_
    hittable[0], meaning that for slat 1 (i.e. index is=0), the right GEANT
    hit is picked, but for the other slats are get wrong hit unless all
    slats with lower number have 0 hits.
    
    A similar argument applies to the case for multiple hits. The nested
    loops always start at index n=0 and thus start mismatches hits and slats
    in the following.
    
    I have thefore redone a lot of the BrDigitizeTof::Event, adding comments
    and in particular taken care of proper matching of hits to slats. I've
    also done some renaming of variables, applying to both header and source
    file. Finally I also found a memory leak in the mentioned function which
    I've taken care of. The arrays dynamically created in the function were
    not deleted.
    
    I guess that those of you who have used TOF digitization for corrections
    etc. should, if possible, try to redo it.
    
    I've checked in the changes, bumped the revision number and tagged. As 
    part of this I commented out BrRecoPackage from Makefile.am, Include.h 
    and LinkDef.h in the packages directory. Thereby, awaiting more info 
    from Pawel and Kris on how to deal with BrRecoPackage BRAT now compiles.
    
    Best wishes from
    Jens Ivar
    
    -- 
               _____________________________________________________
      ________|                  Jens Ivar Jřrdre                   |_______
      \       | Dept. of Physics                        Office: 521 |      /
       \      | Allégt 55                    Phone: +47 55 58 27 92 |     /
        \     | 5007 Bergen                    Fax: +47 55 58 94 40 |    /
        /     | Norway            E-mail: jensivar.jordre@fi.uib.no |    \
       /      |_____________________________________________________|     \
      /__________)                                               (_________\
    


    This archive was generated by hypermail 2.1.5 : Fri Aug 22 2003 - 13:30:36 EDT