I tested the fast offline reconstruction with PXL+IST+SSD full chain. For PXL/IST, all relavant codes and preliminary calibration tables are in place. I only keep the run-by-run PXL masking tables at local directory (which will be populated later).

SSD, I used the latest StSstDaqMaker from Long Z. with the noise table calibration mode. All other relevant SSD codes are copied from Long's directory too (presumably should be syncronized with the offline/hft, please check). I used all the default cuts suggested by Long.

Production chain options:

"ry2015,in,tpcX,AgML,tpcDB,TpcHitMover,Idst,Tree,evout,ITTF,UseXgeom,BAna,l3onl,trgd,StiHftC,analysis,pxlHit,istHit,sst_daq,spt,CorrX,HftMatTree"

HftMatTree modified by Jonathan to include the SSD part. One test run output is stored here

/star/u/dongx/lbl/hft/Run15/Cosmic_ZF/output/

Here are a few event displays showing some candiate cosmic tracks passing through and leaving hits on all 8 HFT layers.

Here are a few more quick looks on the hit distributions and residuals w.r.t to the TPC track projection

1) number-of-hit distributions on each detector

PXL	IST	SSD

PXL/IST distributions look familiar. We will need to do fine adjustments on the masking.
SSD: number of hits per wafter by default cuts from this run is about 100 per event. But one can also see there are quite some noisy wafters. We may further improve the calibrations on these wafers too.

2) Residuals w.r.t the TPC projections
 

PXL	IST	SSD

All show clear correlations for all three detectors. There is a split in the z residual which is likely due to the mis-calibrated TPC drift velocity or T0 (clearly seen in the residual vs. eta).

A few questions/comments on the SSD part

1) On the detector efficiency
By eye-counting from the event displays, I saw about 30 associations on the SSD when I had 50 TPC good tracks that also have a good IST hit in the inner layer. This is probably acceptable also considering a) the SSD acceptance gaps (particularly in Z), and b) if I remember correctly, SSD was typically running with 8-10% dead time during these cosmic runs. To me I feel maybe for the calibration, we can go ahead for the alignment production.

2) Sensor combo Id numbering 
  The ladder/sensor numbering scheme is fixed before. This is related to the code-in sensor combo Id numbering - how to combine the ladder, sensor Ids into one number.
  My understading on what is being used now for SSD is

    for (Int_t i_ladder = 0; i_ladder < 20; i_ladder++) {
      for (Int_t i_sensor = 0; i_sensor < 16; i_sensor++) {
        UInt_t id = 7000 + 100*(i_sensor+1) + (i_ladder+1);
        TGeoHMatrix *comb = (TGeoHMatrix *)ssdRot->FindObject(Form("R%04i", id));

  The definition is a bit odd, sensors on the same ladder will have IDs scattered. And it is not consistent with the PXL and IST systems. I think it will be good to use a consitent defintion for decoding for all three subsystems.

  What is now used on PXL and IST is
  PXL:   sensorID   1-400  with 1-10 belong to one ladder
  IST:    sensorID  1001-1144   with 1001-1006 belong to one ladder

  With the similar scheme, I would like suggest for SSD to use
  SSD:   sensorID  2001-2320   with 2001-2016 belong to one ladder