Star-tpc-l mailing list

["Fisyak, Yuri V" <fisyak AT bnl.gov>]

Hi Zach, we are awaiting your presentation.

 

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

Hi all,

 

I'd like to present some findings regarding the test production at tomorrow's TPC meeting if that's okay.

 

Thank you,

Zach

 

On Fri, Jul 19, 2024 at 12:27 PM Zachary Sweger <zwsweger AT ucdavis.edu> wrote:

When you require nHitsFit>15 and get rid of the nHitsFit/nHitsMax>=0.51 requirement, then the multiplicities are in agreement for the test production and P24ia. I have not yet checked RefMult3. 

 

Quick question that will help with the QA: Does mPicoEvent->eventId() return the same value for the same events in both productions? I saw some strange cumulants when running over the test production and I'd like to do an event-by-event comparison of the productions to see what's going on.

 

Thanks,

Zach

 

On Fri, Jul 19, 2024 at 8:00 AM James Dunlop <dunlop AT bnl.gov> wrote:

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