Star-tpc-l mailing list

[James Dunlop <dunlop AT bnl.gov>]

But then you can't reproduce RefMult by counting the tracks?

What does it do to RefMult3, etc?

--J

On Jul 19, 2024, at 10:58 AM, Fisyak, Yuri V <fisyak AT bnl.gov> wrote:

Jamie, only reason that all physics analyses since iTPC are using 15 hits cut.

 

                                                              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: James Dunlop <dunlop AT bnl.gov>
Date: Friday, July 19, 2024 at 10:50 AM
To: Fisyak, Yuri V <fisyak AT bnl.gov>
Cc: Dunlop, James C <dunlop AT bnl.gov>, zwsweger AT ucdavis.edu <zwsweger AT ucdavis.edu>, Star-tpc-l AT lists.bnl.gov <Star-tpc-l AT lists.bnl.gov>, Van Buren, Gene <gene AT bnl.gov>, Mathias Labonte <mlabonte AT ucdavis.edu>
Subject: Re: [[Star-tpc-l] ] nHitsMax Issue

Hmm.  Why 15?

I believe refmult is still defined as

fit points >= 10

--J

 

On Jul 19, 2024, at 10:26 AM, Fisyak, Yuri V <fisyak AT bnl.gov> wrote:

 

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:

<Screenshot 2024-07-18 at 11.18.28 PM.png>

 

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:

<Screenshot 2024-07-18 at 11.15.08 PM.png>

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

 

--

He/Him/His
Please do not feel obligated to respond to this message outside of your work hours.

James C Dunlop Ph.: (631) 344-7781                       

Building 510A         Cell: (631)316-8153

P.O. Box 5000                      

Brookhaven National Laboratory

Upton, NY 11973

dunlop AT bnl.gov

--

He/Him/His
Please do not feel obligated to respond to this message outside of your work hours.

James C Dunlop Ph.: (631) 344-7781                       

Building 510A         Cell: (631)316-8153

P.O. Box 5000                      

Brookhaven National Laboratory

Upton, NY 11973

dunlop AT bnl.gov