This blog post is in support of RT ticket 3371.

Both plots below show the average number of reconstructed primary tracks per event from nightly test data.
(NB: the nightly tests were run twice on October 18^th because DEV did not initially compile due to missing code from Yuri, and it was then re-compiled and nightly tests were re-run on the 18^th. The effect is that there are sometimes two values shown for the 18^th on the plots and the plotting code didn't necessarily get the order of the two correct when connecting with a line as timestamps aren't that fine grained.)

The top plot is real data (red) and simulated data (green), both for Run 10 AuAu200 nightly tests.

The lower plot shows simulated data for Run 10 AuAu200 (blue), simulated data for Run 7 AuAu200 (purple), simulated data for Run 14 AuAu200 (green), and embedded data for Run 10 AuAu200 (red).
(NB: the Run 7 simulation uses a non-fixed random number seed, which explains the volatility, but there is nevertheless a clear step in the results)

I have highlighted the following events in chronological order:

• October 17^th commit by Yuri to "Restore update for Run XVIII dE/dx calibration removed by Gene on 08/07/2018 "
• November 1^st commit by Yuri for RT ticket 3369, resolving an issue Yuri introduced in February 2017, believed to be the key issue for embedding to match real data as brought forward by the JetCorr PWG
• November 9^th commit by Victor to try to resolve the reconstruction issue Victor introduced in June 2016, believe to be the key issue for inefficient track reconstruction as brought forward by the JetCorr PWG
• November 13^th commit by Victor to retract a possible enhancement that he committed on November 9^th at the same time as the issue resolution codes, leaving only the issue resolution codes in place

Comments on what can be seen regarding Yuri's October 17^th commits:

1. They affect simulation & embedding, not real data reconstruction (unlike Victor's commits, which affect everything), and they affect simulation & embedding by non-trivial percentages that seem very likely to affect efficiency calculations (this has not been proven, but a 17% modification to reconstructed primaries seen in Run 10 simulation would unlikely mean only edge-case tracks are affected; what happened to Run 10 embedding needs understanding too). Which simulation is better: before or after this commit? Do we have a reason for concern about all simulations before this commit?
2. They affect all existing years' simulations; their impact is pervasive.
3. They affect simulation using the older "TRS" TPC slow simulator (as was used for the Run 7 simulation shown), not just the newer "TpcRS" slow simulator. This indicates that the relevant modification is somewhere deeper in the code than at the level of TpcRS (TRS is an independent code). Fixing fundamental code later, after production starts, such that the fixes do not alter reconstruction, may be non-trivial. There is considerable value in fixing this before it goes into any settled libraries.
4. Official productions are not the only users of the simulation and reconstruction codes; there are others doing high priority development work. Making everyone wait for a resolution to known issues needs good justification.

-Gene