STAR task force for evaluating tracking efficiency uncertainty

[David Stewart <david.j.stewart AT yale.edu>]

Hi Grigory et. al,

I have worked on trying to find why the results in the Gmt code are not identical in the .DEV2 to dev library edition transitions. I have tried a few changes, and have compiled some results into this STAR blog file. Perhaps the quick summary below is a good status of where things are:

1. When I ran what I thought were identical inputs for the two library versions, I got results that were different. The ratios of the numbers of entries on some part of the tree in dev to the equivalent output tree in .DEV2 where not consistent for all branches. This led us to think that perhaps the problem is in the StGmtClusterMaker.{h,cxx}files.
2. It appeared that the text input to the BFC in the two library versions had to be slightly different. I have changed that text string to be the same in each library version. They both run
3. The default QA output strings in the *.B.log files indicate that each version is accessing the same Event, Run, and EventId in the same order, but also indicate that the run appears to terminate earlier in one version that the other (usually earlier in .DEV2 than in dev but it is not consistent)
4. It is not apparent to me from the output files why some runs are terminating early
5. Regardless of the same event reading, the results stored in the tree, don’t give the same values for T->Scan("{fNtrack,fTracks.fInvpT}") (a branches chosen at random) at the start of the tree values.
6. While it makes much more sense to run “small” jobs interactively than submitting larger (10 process) condor jobs, it appears that to get a single gmt event, it requires an average of just under 20 minutes of interactive node run time. This is still ok, but makes the investigative loop somewhat cumbersone.

Best,
Dave

David Stewart wrote on 5/6/2021 5:58 PM:

Hi Grigory,
Thank you for the link to Egor's slides. I have looked through them.

My current status is I have verified that the .DEV2 and .dev makers are writing out the same number of `QA :INFO  - StIOMaker:` calls for event, run, and eventid. I have also verified that I can call the .dev code with the same string argument to the bfc.

I have moved onto a larger sample to now reproduce my plots with a new set of data to see if the number of entries in .dev and .DEV2 are similar. These take a long time to run, but are only 18 jobs (i.e. one per each of the sample *.daq files that I have pulled locally) so it's not a terrific strain on resources. Those should finish running tomorrow and then we'll see what is what. I saw some funny things with an earlier result, but that was referencing the daq files in my scratch directory, so I think it's best to wait for these results tomorrow. If all goes well, then those results will be consistent, providing assurance that the .dev simulation is a good migration of the .DEV2 code.

I'm open to questions, comments, and corrections,

Thanks,
Dave

Grigory Nigmatkulov wrote on 5/6/2021 11:37 AM:

Hi David,

I found the slides from Egor: https://drupal.star.bnl.gov/STAR/system/files/Compiling_GMT-software.pdf

Please let us know if you have any questions. Could you please tell what are the steps you are doing now?

Again, sorry that missed the last meeting.

Thanks,

Grigory

On Wed, 5 May 2021 at 18:50, Grigory Nigmatkulov <nigmatkulov AT gmail.com> wrote:

Hi David,

Sorry that I missed the meeting yesterday. What exactly  are you looking for?

Cheers,

Grigory

On Tue, 4 May 2021 at 17:41, David Stewart <david.j.stewart AT yale.edu> wrote:

Hi Grigory,

This morning in the tracking efficiency meeting, Yuri suggested that what I am doing might overlap significantly with work you did in presenting comparisons of the .DEV2 and dev libraries regarding the GMT for a TPC collaboration meeting about a year ago. In interest of efficiency and not redoing your valuable work, could you point me to that presentation?

Thanks very much,

Dave

​