This page documents the ongoing discussion about the use of the FTPC simulator in embedding. 

FTPC embedding request
FTPC embedding history

1) THE PROBLEM:

In December the FTPC embedding QA sample was produced. All looked reasonable except the Nfit comparison between data and matched tracks: http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20101215/ .  Click on the link at the top of the page to view the base QA plots (page 30) that show the mismatch.

2) CHECK STATUS TABLES:   http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20101220/

• Figure 1 is for the online plots say there is a dead RDO board and this means that part of the detector can have only 6 hits - no more
• Restrict nhits > 7 hits and see if hole appears in matched tracks.
• Figure 3 shows the expected dead area so status tables seem correct at least at gross level in the real data and the simulation. Note that ghost tracks are dominated by "real" data tracks in the embedding sample. The fact that ghost tracks match data but matched tracks do not indicate a problem in the simulator or gain/status entries for the simulator.

3) CARL's SOLUTION:   bottom of page: http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110103/

The gross agreement of the dead regions suggest that status tables are not the problem but instead the gains (connected to hit efficiency) may be the problem.
Carl noted that " The 'right way' would be to tune the emulated pedestals, thresholds, pulse heights, etc., to get a good match between data and embedding. This would involve several coupled parameters, so the tuning might take quite a bit of effort'. Instead he offered "If the FTPC hit response in the data is rather uniform (where it's not zero), an easier approach would be to fold in a random number generator that keeps xx% of the hits and rejects the remaining 100-xx% before the tracking is performed. xx would need to be tuned to get a data:MC match. But it's a single knob, so a simple (quasi-)binary search algorithm should find the optimum value rather quickly." Embedding team agrees and decides to pursue this path.

4) APPLY SOLUTION  :  http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110118/

• Technique vastly improves nfit comparison
• Tweak yield/eff trade-offs by removing dead sector

5) NFIT Distributions vs Efficiency: http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110127/

6) Hit Rejection Optimization : http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110208/

7) TWO ADDITONAL CONSTRAINTS: http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110414/

• Janet and Peter have pointed out some necessary fixes to Jim's analysis: 1)apply detector state=="good" for all events 2) remove bad region for set time period
• Excluding the regions of major φ discrepancy allows a decent agreement between data and embedding in terms of φ and NFit. Both distributions optimize agreement with the 23% rejection scheme.

SUMMARY:

• The NFIT distributions of matched tracks and data do not agree like they should.
• The experts have checked the status+ gain tables and found no problems.
• Their suggestions in 7) increase agreement but not sufficiently to make up for discrepancies.
• Possible solution is to apply a hit efficiency tuning algorithm so that efficiencies in simulation are effectively tuned to those in data.
• This procedure has been optimized by removing dead sectors and bad runs.
• The efficiency is now 21.6% via final optimization described in http://www.star.bnl.gov/protected/spin/drach/Run8FMS/FTPC_sim/embedding/20110426/.

THE WORRY:

• This procedure is non-traditional (ok it is a hack) and against embedding policy of using CVS ci code
• Is there a clear path forward to make the simulator to work?
• By implementing this work around are we missing something important (elephants under rocks?)