Tracking Upgrade Review Material



The TUP Review is scheduled for Dec. 7th, 2006, and will consist of material from the HFT, IST and HPD groups. The draft charge for the review will be similar to the HFT review charge, archived here: Tracking Review Committee Charge.

The datasets for the upgrade reviews are archived here.

UPGR05
Hit Occupancy
Pion Efficiency (pt, &eta)
Ghosting (pt, &eta, centrality, pileup)
Pion Acceptance
Hits X,Y
Hit Occupancy
Inter-hit distance (r,centrality)
Cluster Finding Eff. (centrality)
Residuals (r,eta,pt,z,centrality)
DCA (pt,centrality,signal)
UPGR06
Hit Occupancy
Pion Efficiency (pt, &eta)
Ghosting (pt, &eta, centrality, pileup)
Pion Acceptance
Hits X,Y
Hit Efficiency
Inter-hit distance (r,centrality)
Cluster Finding Eff. (centrality)
Residuals (r,eta,pt,z,centrality)
DCA (pt,centrality,signal)


Study

Geometry

IST(1),HPD,HFT IST(1),HFT UPGR06 UPGR09 UPGR10 UPGR11
Hit Occupancy
Pion Efficiency (pt, eta)
Pion Acceptance (pt, eta)
Ghosting (pt, eta, centrality, HFT pileup)
Hits X,Y * * * *
Hit Efficiencies X,Y * * * *
Inter-hit distance (r,centrality)
Cluster Finding Eff. (centrality)
Residuals (r,eta,pt,z,centrality)
DCA (pt,centrality,signal)
Secondary vertex Resolution
(D trajectory verctor, phi, centrality)

IST presentation

Residual and Pull plots (HowTo)

Sti has a nice utility for providing Pull and residual plots for all detectors. The chain option is "StiPulls". The resulting ntuple is written to the .tag.root file.

Among other things, the ntuple stores the (position of the hit - position of the track) in the variables ending in "Pull". It should be noted that the variable contains this difference (or residual), and NOT the difference scaled by the error. This is left for the user. There are several branches of the pulls tree; one for global tracks, one for primary tracks, and one filled only during the outside-in pass of tracking.

The outside-in pass is stored in the branch mHitsR, as described in Victor's post. The information stored here is the residual between hit and track positions, before the hit is added to the track. This information is useful for evaluating the progresion of the track error as the tracker steps in toward the vertex. It's also essential for those of us trying to evaluate potential detector configurations.

So, to evaluate the track residual, on can simply use the root command prompt:

root> StiPulls->Draw("mHitsR.lYPul>>residual","mHitsR.lXHit<5. && mHitsR.lXHit>2.2")

This will give you a histogram "residual" which has residuals in &phi for hits from the inner HFT only ( 2.2cm< inner HFT < 5.cm). One can also use the detector id, which is also stored in the tree.

For residuals as a function of Pt, one can try:
root> StiPulls->Draw("mHitsR.lYPul:mHitsR.mPt>>residualPt","mHitsR.lXHit<5. && mHitsR.lXHit>2.2")
root>residualPt->FitSlicesY()
root>residualPt_2->Draw()
This gives you a plot comparable to the pointing resolutions derived in Jim's hand calculations.


This page is a compilation of posts to the ittf hypernews list (Victor's original post, Mike's requested changes, and Victor's response), as well as documents provided by the STAR S&C group (StiPullEvent, StiPullHit, and StiStEventFiller).

Tracking Review Committee Charge

The charge to the Review Committee for evaluation of the HFT proposal is archived here. The online document can be found under http://hepwww.physics.yale.edu/star/upgrades/Draft-Charge.pdf

The Review Committee is asked to review the proposed tracking upgrades to STAR and to comment on the following:

1. Scientific Merit: Will the proposed detectors significantly extend the physics reach of STAR? Is the science that will be possible with the addition of this upgrade sufficiently compelling to justify the proposed scope of the project?

2. Technology Choice and Technical Feasibility: Are the proposed technologies appropriate, viable, and robust; are there outstanding R&D or technical issues which must be resolved before proceeding to a fully detailed construction plan covering technical, cost, and schedule issues?

3. Technical specifications: Are the physics-driven requirements for this detector sufficiently understood, and will the proposed mechanical and electronics implementations meet those requirements? Is the proposed design reasonably optimized? Is the proposed scope of the upgrade justified by the physics driven requirements?

4. Detector Integration: Is the impact of integrating this detector into STAR understood and manageable: are there potential "show-stoppers" with regard to mechanical support, utilities, cabling, integration into trigger, DAQ, etc.?

5. Resources, Cost, and Schedule: Is the costing of the detector realistic; is the basis of estimate sound; has the full scope been included in the estimate; is the level of contingency realistic? Does there appear to be sufficient manpower to carry the project out successfully – including manpower for developing calibration and analysis software? Is the technically driven schedule achievable?