Code QA for psn0667

support documents : http://www.star.bnl.gov/protected/lfsupc/xyf/Hypertriton/analysis_page/index.html
original code CVS location : $CVSROOT/offline/paper/psn0667
my working directory: rcf /star/u/xgn1992/work/CodeQA/Hypertriton/offline/paper/psn0667

With the help of the authors (Yifei), the code QA was summarized here with several main items.

1, Library issue. - solved
  The original source code can not be compiled with the recommended STAR library "SL10k" or "pro" ( SL10k was removed from rcf).
  Slight modifies on the grammar, then can run through the codes.

2, When extracting the raw yield, looks like in the code the used mass window range is different from the paper.
  Should keep everything consistent, this one related to the bin width is 2MeV or 4MeV.

3, When extract the raw yield, the (signal+background) was estimated by the bin counting method from the "unlike-sign" histogram.
  The (background) was estimated by fitting "rotated-histogram" with exponential function.
  Background counts were integral from the fitting function within the mass window, but the background error were not seriously taken care of (set to 0).
  Informed the authors, need to discuss in detail and give an explanation why choose this method.
  PS: there are several other method can be used to extract raw yield, each of them already consider the bkg fluctation contribution, such as 1) directly from the Fitting of unlike-sign, 2) HIST_Counts(unlike-sign) - HIST_Counts(rotate-sign). Are these method give consistent results? The difference can be taken care as sys. ?
 
  Update: authors explain that the background fluctuation can be reduced by rotate the background many times.
  -- agree that increase rotating times can reduce the bkg at some point, but not sure the method used here is suitable or not.
  -- Method used here: Only rotate one time (180 degree), then fitting, integral fitting function without consider the fitting error.
  -- Messages from authors, they tried rotate 3 different degrees, the background shape doesn't change much, the bkg counts from fitting doesn't change much
    --> should this be considered as sys. source ?

  Problems:
  -- bkg function IntegralError is huge, more than 100% from the fitting

  -- the 0.95 confident band from fitting is also visible
  -- there are some difference between the fitted signal yield from unlike-sign method and the yield using the paper method

  Update from the authors:
  -- "The normal way to do it is directly subtraction, but as you know, it will introduce uncertainty due to the limited statistics in background analysis. If we increase the statistics in background, like rotated many times (we did it more serous in 2-body analysis), or mixed event by increase the buffer size, the background shape will come to a smooth distribution eventually. This is the reason why we used fit function to estimate the background level.
You suggested other method like combined fit with signal + background directly is another way we did it. The difference between combined fit and bin-bin count is taking as systematic uncertainty."

  Fitting parameters:  

4, Based on my understanding, from the source code, the 3-body decay Length binning (L/#beta#gamma) should be [2,8,13,25], not the paper said [2.4, 8, 13, 25]. Please confirm and fix this or correct me if i am wrong.
  -- Indeed the binning start from 2.4, the authors (Yifei) point out there is a default cut on the picoTree analysis level.
  -- Done

5, Can you elaborate why the table I and II in the paper have different #Events for the same energy while the event level cut is the same.
    Since this number will be used in the combined efficiency calculation and also InvYield for He3.

6, For the efficiency correction, looks like the PID part was not taken care of for different energy. Is this true or am i wrong? should we consider this or not?

7, With the help of the authors (Yifei), the Chi2 was tested. the support documents can be found from the attachment. 

8, The bin width effect for decay-Lenght was tested.
    My understanding is using the next method, but looks like the method and results are different with the author's. Need to discuss in detail. 
    - http://www.star.bnl.gov/protected/heavy/marr/Analysis/PlaceDataPoints.pdf 
  -- The method used in the paper can be found attached, agree that this is one way to present the data point.

In summary, the source code can run through smoothly.