I processed two different sets of data for track-by-track comparison purposes:

1. Run 13 pp510: 500 events from st_physics_14079008_raw_1920004.daq
2. Run 14 AuAu200: 500 events from st_physics_15164004_raw_2000022.daq

I used 4 different libraries, where EVAL as of this date contains the StiCA_2016 tagged codes.

1. SL16b
2. SL16b optimized
3. EVAL
4. EVAL optimized

First, some general notes & observations:

• For pp510, I used all 4 libraries somewhat successfully.
  • EVAL optimized introduced "nan" values in one of my comparions quantities, which I ignored for this study: error on the DCA, which is an argument value returned by the function THelixTrack::Dca(), as defined in $STAR/StRoot/StarRoot/THelixTrack.*
• For AuAu200, I used only the non-optimized libraries. This I did because the EVAL optimized jobs aborted quickly, reporting the following:
  

  root4star: .sl64_gcc482/obj/StRoot/StarRoot/THelixTrack.cxx:802: double THelixTrack::Step(const double*, double*, double*) const: Assertion `iter' failed.
  *** Problem in THElixTrack::Step(vtx) ***
  double vtx[3]={-nan,-nan,-nan};

  Clearly there is an issue with the THelixTrack class in optimized EVAL.
• SL16b optimized and unoptimized gave identical results within the precision that I used for my comparison values. I believe if one uses higher precision, we've seen occasional differences in the least significant digits due to rounding. Thus, I will show no plots comparing SL16b (unoptimized) to SL16b optimized.
• Cuts to match tracks (by proximity) were the defaults:
  
  • Δ(q/p_T) < 0.1 [GeV/c]^-1
  • Δ(η) < 0.1
  • Δ(φ) < 0.15 [rad]
• Cuts to select "good tracks" for use in matching were the defaults:
  • N_hits ≥ 25
  • Either a BEMC or BTOF match
  • 3D DCA < 4 cm to a primary vertex with...
    • rank ≥ 0 (pp510) or rank ≥ -5 (AuAu200)
    • daughter multiplicity ≥ 5
    • daughters matched to BEMC ≥= 1
    • |z_TPC - z_VPD| < 5 cm

---

Run 13 pp510 comparisons:

Reconstruction chain: pp2013a,btof,VFPPVnoCTB,beamline,BEmcChkStat,CorrX,OSpaceZ2,OGridLeak3D,SCScalerCal,goptSCE100051,-hitfilt

Correlations and ratios of reconstruction time per event: unoptimized EVAL is a little slower, while optimized EVAL is notably faster.
(Note 1: all 4 chains run at the same time, on the same node, using the same local disk)
(Note 2: first event is the slow outlier as it includes initialization overheads)


Number of "good tracks" used for my comparisons: EVAL optimized has more than SL16b, and unoptimized has fewer.

SL16b	131612
SL16b optimized	131612
EVAL	131201
EVAL optimized	131887

Track-by-track matching: optimized EVAL seems to introduce the most mis-matches.

A vs. B	matched	unmatched A	unmatched B
SL16b vs. EVAL	131120	492	81
SL16b optimized vs. not	131612	0	0
EVAL optimized vs. not	130105	1782	1096
SL16b optimized vs. EVAL optimized	130083	1529	1804

SL16b vs. EVAL:

	"zcol"	"profs"	"prof"
Δ(q/pT)/(q/pT) vs. Nhits
Δ(sDCA) vs. Nhits
Δ(Nhits) vs. Nhits

EVAL optimized vs. not:

	"zcol"	"profs"	"prof"
Δ(q/pT)/(q/pT) vs. Nhits
Δ(sDCA) vs. Nhits

SL16b optimized vs. EVAL optimized:

	"zcol"	"profs"	"prof"
Δ(q/pT)/(q/pT) vs. Nhits
Δ(sDCA) vs. Nhits
Δ(Nhits) vs. Nhits

---

Run 14 AuAu200 comparisons:

Observations are very similar to what was seen in Run 13 pp510.

Reconstruction chain: P2014a,btof,BEmcChkStat,CorrX,OSpaceZ2,OGridLeak3D,SCScalerCal,goptSCE100051,-hitfilt

Correlations and ratios of reconstruction time per event: unoptimized EVAL is a little slower.
(Note 1: both chains run at the same time, on the same node, using the same local disk)
(Note 2: first event is the red marker; it includes initialization overheads)


Number of "good tracks" used for my comparisons: EVAL unoptimized has fewer than SL16b unoptimized, just like with Run 13 pp510.

SL16b	176359
EVAL	175727

Track-by-track matching: similar to the Run 13 pp510 results.

A vs. B	matched	unmatched A	unmatched B
SL16b vs. EVAL	175655	704	72

SL16b vs. EVAL:

	"zcol"	"profs"	"prof"
Δ(q/pT)/(q/pT) vs. Nhits
Δ(sDCA) vs. Nhits
Δ(Nhits) vs. Nhits

-Gene