Skip to Content.
Sympa Menu

star-tpc-l - Re: [[Star-tpc-l] ] nHitsMax Issue

star-tpc-l AT lists.bnl.gov

Subject: Star-tpc-l mailing list

List archive

Chronological Thread  
  • From: "Fisyak, Yuri V" <fisyak AT bnl.gov>
  • To: "zwsweger AT ucdavis.edu" <zwsweger AT ucdavis.edu>, "Star-tpc-l AT lists.bnl.gov" <Star-tpc-l AT lists.bnl.gov>
  • Cc: "Van Buren, Gene" <gene AT bnl.gov>, Mathias Labonte <mlabonte AT ucdavis.edu>
  • Subject: Re: [[Star-tpc-l] ] nHitsMax Issue
  • Date: Fri, 19 Jul 2024 14:26:16 +0000

Hi Zach, thank you for the plots.

   In TFG the track reconstruction (CA) it is allowed to reconstruct loopers, .i.e. different track segments from track loop are merged.

This is the reason why you have no. of reconstructed and possible hits are more than number of pad rows.

In TFG version it has been introduced a cut on 15 hits in conversion MuDst => PicoDst  

 

$STAR/StRoot/StMuDSTMaker/COMMON/StMuDst.cxx:111

#else /* __TFG__VERSION__ */

Int_t StMuDst::MinNoTpcMcHits = 15;

Int_t StMuDst::MinNoTpcRcHits = 15;

StRoot/StPicoDstMaker/StPicoDstMaker.cxx:1048:    if ( !mMuDst->Accept(pTrk) ) continue;


                                                              Yuri Fisyak

STAR                                           Phone: +1 631 344 3913
Brookhaven National Laboratory  Fax:    +1 631 344 4206
510A/1-161
http://www.star.bnl.gov/~fisyak       E-mail: fisyak AT bnl.gov

 

 

 

From: Zachary Sweger <zwsweger AT ucdavis.edu>
Date: Friday, July 19, 2024 at 2:33
AM
To: Star-tpc-l AT lists.bnl.gov <Star-tpc-l AT lists.bnl.gov>
Cc: Van Buren, Gene <gene AT bnl.gov>, Fisyak, Yuri V <fisyak AT bnl.gov>, Mathias Labonte <mlabonte AT ucdavis.edu>
Subject: nHitsMax Issue

Hi TPC Experts, 

 

As we discussed this morning, the primary (DCA<3cm) track multiplicity in the test production of 3.2 GeV is lower than in P24ia. Most analyzers require that each track have nHitsFit/nHitsMax>=0.51. After our discussion this morning, I plotted nHitsFit versus nHitsMax (labeled nPossible) and I noticed that many tracks (DCA<3cm) in the test production have very large values of nHitsMax:

 

The red line shows the nHitsFit/nHitsMax=0.51 cut. Another strange thing in the right plot is the lack of tracks with nHitsFit<15. How can so many tracks have nHitsMax values greater than 72? I also tested for tracks with |eta|>2 for which we expect nHitsMax<~40 and saw many tracks still with surprisingly large nHitsMax values:

Were there any changes to how nHitsMax is calculated in the test production? I'm accessing this variable from the picoDsts via 

mPicoTrack->nHitsMax();

 

Thanks!

Zach




Archive powered by MHonArc 2.6.24.

Top of Page