|
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) |
|
|
|
|
|
|
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?