[]{#__RefHeading___Toc485060082 .anchor}Report of the STAR Tracking
Review Committee

June 8, 2000

*STAR Tracking Review Committee Membership:*

Thomas Ullrich (Yale), *chair*

Rene Bellwied (Wayne State)

Les Bland (Indiana)

Yuri Fisyak (BNL)

Mike Lisa (Ohio State)

Claude Pruneau (Wayne State)

Karel Safarik (CERN - ALICE)

Jack Sandweiss (Yale)

Steve Wagner (SLAC - BaBar)

Howard Wieman (LBNL)

Tim Hallman, *ex-officio*

John Harris, *ex-officio*

Jay Marx, *ex-officio*

Matthias Messer, *ex-officio*

Torre Wenaus, *ex-officio*

# Executive Summary

We present here the Executive Summary of the report of the STAR Tracking
Review Committee.

The review was initiated on March 29, 1999 by the STAR Computing Project
Leader and the STAR spokesman with the following mandate:

1.  *To evaluate the state of the STAR software for tracking in the time
    projection chamber and the global reconstruction. The software
    packages associated with cluster finding, track finding, vertex
    finding, and TPC detector response simulation shall be included in
    the review. The evaluation should include among other things general
    performance, tracking efficiencies, details of the types of tracking
    inefficiencies, particle identification capabilities.*

2.  *To evaluate, as above, present codes and plans for tracking near
    mid-rapidity in STAR using the SDD and SSD.*

3.  *To determine the capabilities and plans for extending tracks found
    in the TPC to other STAR detectors (SDD, SSD, EMC, RICH) and to
    evaluate the efficiencies for tracking and particle identification.*

4.  *To identify tracking issues for the present tracking codes that can
    be addressed in the short term (\<6 months) both for the TPC alone
    and for tracking in/to other STAR detectors.*

5.  *To identify tracking issues with the TPC and other STAR detectors
    not addressable with present codes in the short term but requiring
    longer term (6-12 month) upgrades or development. In this context
    the committee may wish to suggest approaches and directions for such
    development. Such suggestions are welcome, but the review is not
    intended as a forum for general discussion of tracking scenarios.*

*The review report will be advisory to the Computing and Software Leader
and the Spokesman.*

The information presented here is a summary derived from a 20-page
report prepared by the committee. Readers wishing to understand the full
context of the various recommendations presented here are urged to
review the full report.

## Findings and Recommendation

In the report we discuss each of the issues below in some detail and
offer recommendations for steps that would redress them. The major
findings and recommendations are presented below.

### Management Issues

While recognizing the most important progress which the tracking and
reconstruction software workers have achieved we believe the managerial
structure which has been in place has not been at a sufficient level.

-   At the level of the STAR Council and Spokesman, offline
    reconstruction must be recognized as being of extreme importance to
    the success of the experiment. Indeed, it may warrant special
    attention because it does not have the same constituency structure
    as the detectors, and because of its cross-cutting and often
    invisible nature.

```{=html}
<!-- -->
```
-   The management also needs to evaluate the progress against clear
    milestones and it must be able to respond appropriately if the
    milestones are not met.

-   The Reconstruction Project Leader should promote a clear vision for
    the evolution of tracking software within STAR and, together with
    the Computing Project Leader, should take the necessary formal steps
    to secure commitments from institutes to provide the required
    support.

### TPC Related Issues

The TRS package is relatively mature, maintainable, and the level of
realism achieved should be sufficient for the most common efficiency
studies. However, the absence of TRS in the chain currently hampers the
evaluation/testing of the clusterfinder and other components.

-   The top action item, which the committee recommends should be taken
    immediately, is integration of TRS into the existing chain (BFC).
    Although further action items have been identified (see below) we
    feel that none of them are showstoppers.

```{=html}
<!-- -->
```
-   We recommend that the TRS developers work with the database team to
    incorporate the interface to the calibration database soon after
    integrating TRS into the BFC.

```{=html}
<!-- -->
```
-   The committee recommends that speed optimization of TRS be pursued
    at this point.

```{=html}
<!-- -->
```
-   We recommend to soon identify a person for TRS, who feels personally
    responsible for its maintenance, upgrades, and tuning.

Overall, the TFS package is an well-understood and much-exercised
software tool. Its \"reality level" is generally reasonable. One problem
raises from the fact that the current clusterfinder does not provide
reasonable uncertainty values while the current also supplies
information on resolution directly to the tracking code. This violates
the understanding of package purpose since the flow of information
differs for TFS and TRS/raw data.

-   The committee recommends to modify TFS such that it does not provide
    the resolution used to generate the individual hits but rather
    derive this quantity in the proceedings steps as is the case for TRS
    and raw data.

The performance of the overall event reconstruction in cosmic ray,
laser, and RHIC beam-gas events, in addition to the earlier simulation
studies on the unimproved code, provides some confidence that TCL and
TPT are basically ready for year-1 data reconstruction and physics
analysis using its output. The committee finds that some points still
deserve attention:

-   It appears clear that the time is right to perform hotspot checks on
    the clusterfinder (TCL), and do simple optimization.

```{=html}
<!-- -->
```
-   The committee recommends that more sophisticated use of currently
    existing STAR wide evaluation tools (in particular, the
    StMcEvent/StAssociationMaker) be developed for use with the
    clusterfinder.

```{=html}
<!-- -->
```
-   In light of the experiential fact that, without crossing angle
    information (available only at the track level), reliable position
    uncertainties cannot be obtained, the committee recommends *not* to
    invest effort in trying to calculate these uncertainties in the
    clusterfinder.

```{=html}
<!-- -->
```
-   The committee feels a top priority must be to generate hit-wise
    position uncertainties based on the local track parameters in all
    cases- i.e. even for the fast simulator.

```{=html}
<!-- -->
```
-   Instead of further evaluation the magnitude of the pattern
    recognition (root formation) bias, the committee recommends
    implementing the fix. It was stated that the route to elimination of
    this potential problem is understood, and a fix would take about 1
    week\'s work.

```{=html}
<!-- -->
```
-   The solution to the above point involves a rapid estimate of the
    position of the primary vertex which we recommend to implement soon.

-   The committee perceives that a rather small group of people is
    simultaneously *developing/maintaining* the tracker as well as
    *evaluating* it, and recommends that much more evaluation be done by
    STAR collaborators outside of this group.

```{=html}
<!-- -->
```
-   The committee recommends a careful evaluation of the distribution of
    the innermost padrow of the first correct hit on a track, to probe
    for potential problems.

In much of the evaluation discussed during the review, tracker
evaluation centered largely on the correspondence between the
reconstructed track, and the corresponding Monte Carlo track which was
its best match according to the number of hits in common. In the terms
used during the review, reconstructed/generated track pairs with the
highest \"qfact\" were mostly considered. The committee worries that
evaluations focussing on the largest-qfact matches may miss important
information on ghosts and momentum resolution.

-   We recommend that further evaluation efforts of tracks not center as
    exclusively on the largest-qfact.

### SSD/SDD Related Issues

The committee was impressed by the very large efficiency and purity
achieved by the SSD Hit Finder.

The SDD Fast Signal Generator is not yet in a state such that it could
be included in the STAR reconstruction chain.

-   An actual simulator of the digitized SDD signals is expressly needed
    to perform truly realistic simulations of the detector performance
    and, in particular, to optimize the cluster finder.

The committee recognizes that standalone track finding in the SVT based
on a set of 3 or 4 points is clearly not very well constrained. Such a
weak constraint can lead, in a standalone mode, to the reconstruction of
a large number of ghost tracks. Track fits based on 3 or 4 points may
not practically be amenable to more sophisticated treatments: standalone
tracking and fitting, except for the lowest momentum of interest, does
not appear a very viable long term strategy for STAR and SVT tracking.
The results presented on SVT track to TPC track matching reflect the
difficulty of the task and are no doubt the best indicator of the
difficulty of the task at hand.

-   The committee strongly recommends that a careful analysis be
    conducted to determine the inter-relation between the number of
    ghosts and the reconstruction efficiency for the SVT standalone
    tracker. The emphasis of this analysis should be on secondaries
    which constitute "la raison d'être" of the SVT.

The results on TPC track to SSD/SVT point matching were quite
encouraging. On the onset, this tracking technique appears promising.

-   We propose that the SVT group (including Nantes collaborators),
    while maintaining an optimization effort of the existing standalone
    tracker and matcher, should invest seriously in the development of a
    vector-to-point matcher in the spirit of the work presented by the
    Nantes group.

```{=html}
<!-- -->
```
-   Concerning the TPC track to SSD/SVT point matching we strongly
    recommend that the association of hits to the TPC tracks should make
    use of a tree structure: i.e. initially, SSD/SDD points should be
    allowed to be associated to more than one TPC tracks so one can
    evaluate which of the associations has the best quality rather than
    using, as in the analysis presented at the review, a "first tested
    gets the track" approach.

-   Early passes in TPC track to SSD/SVT point matching procedure should
    include the main vertex i.e. one should try to associate SSD/SDD
    points which fall near/on an extrapolation of TPC tracks leading to
    the main vertex. We recommend that a Kalman filter approach would
    readily solve the problems involved in taking scattering into
    account.

-   The matching algorithm should include the possibility to turn off a
    layer of the inner detector: i.e. on the onset, the tracker should
    be built to accommodate either a three-layer SVT, or an SVT+SDD four
    layer detector.

### Global Reconstruction 

The committee sees all tasks concerning year-1 global reconstruction
well addressed by the existing code but also recognizes that the group
is seriously understaffed to achieve the goals for year-2. We fully
agree with the view of the Reconstruction Project Leader that at least
2-3 more full time people are needed in the near future to accomplish
the task. We also make the following recommendations:

-   For global tracks we recommend to store position and tracking
    parameters at the first *and* the last point in the TPC (using the
    Kalman fitter). We also propose to perform the extrapolation of
    global tracks to the non-tracking detectors (RICH, EMC, TOF) already
    during the 'global' reconstruction and store the momentum vector,
    position and error at the intersection together with the tracks.

```{=html}
<!-- -->
```
-   Regarding the Kalman fitter program for global tracks, the actual
    improvements on the physics have to be better documented.

```{=html}
<!-- -->
```
-   Work on the Kalman fitter should include the primary vertex and thus
    requires a material propagator program (e.g. GEANE) that allows the
    inclusion of effects based on the IFC, gas, and beam pipe material.

The primary vertex finding program (EVR) seems to perform well, but it
seems to also cause some problems during the running of the BFC.
Presently the improvements in the primary vertex resolution from year-1
to year-2 are only a factor 2, which is in contradiction to the vastly
increased impact parameter resolution when including the SVT.

-   We recommend to re-write the EVR code and make it more stable.

### Future Planning

We recognize the short-term plans presented by the Project Leader as
reasonable, especially since the address many problems that are also
part of our findings.

In general the committee welcomes the long-range plans as presented,
although it feels that the detail of information available is not
sufficient to fully understand its implications. This is in part due the
fact that the reconstruction group itself is still reflecting on these
issues and that it has not yet finalize their detailed plans.

-   The Reconstruction Project Leader should officially form an R&D
    group which aims at developing an improved and coherent tracking
    approach incorporating all tracking detectors. The *scope* of the
    effort should be well documented and a set of milestones should be
    defined precisely. All efforts have to be balanced vs. the need to
    maintain and, where possible, improve the current implemented
    tracking software, i.e. any new R&D efforts should not jeopardize
    current accomplishments.

# Table Of Content

Report of the STAR Tracking Review Committee
[1](#__RefHeading___Toc485060082)

1 Executive Summary [2](#executive-summary)

1.1 Findings and Recommendation [2](#findings-and-recommendation)

1.1.1 Management Issues [2](#management-issues)

1.1.2 TPC Related Issues [3](#tpc-related-issues)

1.1.3 SSD/SDD Related Issues [4](#ssdsdd-related-issues)

1.1.4 Global Reconstruction [4](#global-reconstruction)

1.1.5 Future Planning [5](#future-planning)

2 Table Of Content [6](#table-of-content)

3 Introduction [7](#introduction)

4 Organization of Project [8](#organization-of-project)

5 Tracking in Main TPC [8](#tracking-in-main-tpc)

5.1 TPC Slow Simulator [9](#tpc-slow-simulator)

5.1.1 Committee\'s understanding of generic package purpose
[9](#committees-understanding-of-generic-package-purpose)

5.1.2 Review of existing implementation - TRS
[9](#review-of-existing-implementation---trs)

5.2 TPC Fast Simulator [10](#tpc-fast-simulator)

5.2.1 Committee\'s understanding of generic package purpose
[10](#committees-understanding-of-generic-package-purpose-1)

5.2.2 Review of existing implementation - TFS
[11](#review-of-existing-implementation---tfs)

5.3 TPC Clusterfinder/Hitfinder [12](#tpc-clusterfinderhitfinder)

5.3.1 Committee\'s understanding of generic package purpose
[12](#committees-understanding-of-generic-package-purpose-2)

5.3.2 Review of existing implementation - TCL
[12](#review-of-existing-implementation---tcl)

5.4 TPC Tracker [14](#tpc-tracker)

5.4.1 Committee\'s understanding of generic package purpose
[14](#committees-understanding-of-generic-package-purpose-3)

5.4.2 Review of existing implementation - TPT
[14](#review-of-existing-implementation---tpt)

6 SVT Tracking [16](#svt-tracking)

6.1 SRS -- SDD Fast Signal Simulator
[16](#srs-sdd-fast-signal-simulator)

6.2 SSS -- SDD Slow Signal Simulator
[16](#sss-sdd-slow-signal-simulator)

6.3 SSD Simulators [17](#ssd-simulators)

6.4 SCL - SDD Hit Finder [17](#scl---sdd-hit-finder)

6.5 SSD Hit Finder [17](#ssd-hit-finder)

6.6 Track Finder [18](#track-finder)

6.6.1 SVT Standalone tracker [18](#svt-standalone-tracker)

6.6.2 TPC Track to SSD/SVT Points Matching (vector to point)
[19](#tpc-track-to-ssdsvt-points-matching-vector-to-point)

6.7 SVT -- TPC Track Matching (Vector-to-Vector)
[20](#svt-tpc-track-matching-vector-to-vector)

6.8 Generic Comments on SVT-TPC Matching, Errors, and Performance
Evaluation
[20](#generic-comments-on-svt-tpc-matching-errors-and-performance-evaluation)

7 Global Tracking [21](#global-tracking)

7.1 Year-1 Global Tasks [21](#year-1-global-tasks)

7.2 Year-2 and Year-3 Global Tasks [21](#year-2-and-year-3-global-tasks)

7.3 Manpower [22](#manpower)

8 Future Planning [22](#future-planning-1)

8.1 Long Term Plans [22](#long-term-plans)

8.1.1 Committee\'s understanding of proposed plans
[22](#committees-understanding-of-proposed-plans)

8.1.2 Comments and Recommendations [22](#comments-and-recommendations)

9 Appendix [24](#appendix)

9.1 Agenda of the Tracking Review Meeting
[24](#agenda-of-the-tracking-review-meeting)

# Introduction

In this report we present an assessment of the state of readiness of
STAR offline tracking software and propose recommendations for short and
long term planning. The STAR Tracking Review was initiated on March 29,
1999 by the STAR Computing Project Leader and the STAR spokesman with
the following mandate:

6.  *To evaluate the state of the STAR software for tracking in the time
    projection chamber and the global reconstruction. The software
    packages associated with cluster finding, track finding, vertex
    finding, and TPC detector response simulation shall be included in
    the review. The evaluation should include among other things general
    performance, tracking efficiencies, details of the types of tracking
    inefficiencies, particle identification capabilities.*

7.  *To evaluate, as above, present codes and plans for tracking near
    mid-rapidity in STAR using the SDD and SSD.*

8.  *To determine the capabilities and plans for extending tracks found
    in the TPC to other STAR detectors (SDD, SSD, EMC, RICH) and to
    evaluate the efficiencies for tracking and particle identification.*

9.  *To identify tracking issues for the present tracking codes that can
    be addressed in the short term (\<6 months) both for the TPC alone
    and for tracking in/to other STAR detectors.*

10. *To identify tracking issues with the TPC and other STAR detectors
    not addressable with present codes in the short term but requiring
    longer term (6-12 month) upgrades or development. In this context
    the committee may wish to suggest approaches and directions for such
    development. Such suggestions are welcome, but the review is not
    intended as a forum for general discussion of tracking scenarios.*

*The review report will be advisory to the Computing and Software Leader
and the Spokesman.*

Information relevant to the work of the Committee was derived from the
review meeting itself held May 4-5 at LBNL, from information compiled by
the Reconstruction Project Leader for the review, from the referring
project web sites, from interviews with numerous members of the
collaboration, and from many interactions with the computing projects
and subprojects leaders.

The committee membership was derived principally from the STAR
collaboration, but the committee greatly benefited from having one
member from the BaBar experiment at SLAC and one from the ALICE
experiment at CERN.

In just a few weeks from now STAR will be faced with the first 'real'
events which deploy track multiplicities never recorded before. It is a
good time to review the readiness of the tracking software to meet the
needs of the year-one STAR physics program, and to assess the ongoing
development and upgrade program to ready the software for year two
physics. As expressed in the charge above the review focussed on the
status and plans for the software relative to year

one and year two physics needs.

In this report we present the analysis of 5 major issues related to the
state of tracking in STAR: Organization (Sec. 4), TPC tracking (Sec. 5),
SVT tracking (Sec. 6), global tracking (Sec. 7), and future planning
(Sec. 8). In covering these topics we believe we have spanned all of the
issues raised in the charge.

This report covers the state of STAR tracking software from spring 2000.
Changes in a variety of areas were underway throughout the review and we
have tried to accommodate our conclusions accordingly.

The wide ranging nature of our recommendations is not intended to be a
refutation of the many dedicated individuals who have worked tirelessly
on STAR tracking software up until now. Indeed, the committee recognizes
that without their previous efforts, many of the current recommendations
for advancement would not even be available for us to consider.

It is the expectation that for each recommendation offered by the
committee and accepted by the management a follow-up mechanism will be
established. We are all aware of how difficult it is to keep certain
issues at the forefront of attention in a situation where new challenges
are being presented every day. We want to respectfully note, however,
that many of the points we raise in our recommendations are critical to
the success of the experiment and should be carefully monitored.

# Organization of Project

The unique strength of the STAR detector is its ability to track all (or
nearly all) of the charged particles within its large acceptance. The
charged particle tracking is key to all of the STAR physics goals,
including those that use the ancillary detectors such as the SVT or the
EMC. Indeed, the TPC alone permits very interesting physics studies
while the ancillary detectors without TPC tracking are at best,
marginally useful. Thus the track reconstruction software is central to
the role of the STAR detector and must be viewed as a \"mission
enabling\" component of the detector. The level of effort and the
managerial effort needed to insure its success must be provided by the
collaboration.

At the level of the STAR Council and Spokesman, offline reconstruction
must be recognized as being of extreme importance to the success of the
experiment. Indeed, it may warrant special attention because it does not
have the same constituency structure as the detectors, and because of
its crosscutting and often invisible nature.

The software effort is complex and challenging. No other detector has up
till now faced a tracking problem of the size and scope of that
presented by STAR. Successful progress clearly requires a number of
talented scientists working in a coherent and effective manner. The
effort needs a clear management structure with the ability to
efficiently integrate a number of different scientists (likely not all
at the same location), to set realistic and adequate goals for near term
(e.g. year one), mid term, and longer term reconstruction software. The
management needs to structure the effort on the different time scales in
the best manner. For example the longer-term effort might involve a
tracking research and development group, etc. The management also needs
to evaluate the progress against *clear milestones* and it must be able
to respond appropriately if the milestones are not met. The software
management must be concerned, of course, not just with the creation of
the software but with its *maintenance* and *evolution* as well. While
recognizing the most important progress which the tracking and
reconstruction software workers have achieved - indeed, future efforts
will surely build upon these - we believe the managerial structure which
has been in place has not been at the level described above.

The Reconstruction Project Leader should promote a clear vision for the
evolution of tracking software within STAR and, together with the
Computing Project Leader, should take the necessary formal steps to
secure commitments from institutes to provide the required support.
Members of the collaboration themselves must appreciate the very complex
nature of offline reconstruction tasks in general and more of us must be
willing to commit useful blocks of time to work on significant
detector-related computing projects.

# Tracking in Main TPC

The committee acknowledges the excellent progress made by the TPC
software group in the development of TPC tracking software. The
committee recognizes in particular the outstanding efforts of Iwona
Sakrejda in the coordination and implementation of tracking software.

In the following, we group discussion according to the software packages
which perform the basic functionality of track simulation and
reconstruction. For each package, we give a brief generic description of
what the package should do. We do not summarize the presentations
themselves, which naturally contain much more detail about the existing
implementations.

## TPC Slow Simulator

### Committee\'s understanding of generic package purpose 

The task of the TPC slow simulator is to interface with GEANT, which
provides the energy deposited into the TPC gas by ionizing particles.
This information is provided as a series of \"hits,\" each with a
position and amount of energy loss. From this information, the slow
simulator generates the expected detector response, accounting for
relevant physical processes in the gas determining the electron
transport through the gating grid and to the proportional wires,
electron avalanche on the wires and wire-to-pad coupling generating the
analog signal, and analog and digital electronics response, including
ASIC and DAQ logic. The end result should be data that is identical in
format (compressed ADC-counts) and, ideally, in content, to what the DAQ
would provide if the STAR TPC triggered on the event (in \"real life\")
which was originally input into GEANT.

The simulator must account for a large number of complicated processes,
each of which in principle can entail a detailed (and CPU-hungry)
calculation. Generating reasonable statistics while treating each effect
to the fullest extent of our knowledge would easily overwhelm any
computing facility, rendering the simulation tool useless. Usually, a
faster parameterization of a process can be used, which is \"almost as
good.\" Care must be taken to judge the overall effects of such
simplifications, playing off CPU performance against depth of detail.
Ideally, the compromise should be adjustable.

Although in principle not representing a distinct functionality for this
software package itself, it is worthwhile to bear in mind that, as real
data becomes available, it is foreseen that the primary use of the slow
simulator will be to simulate the pixel patterns corresponding to a
small number of tracks, and then to merge these simulated signals with
real data events, which (of course) contain realistic noise and
contamination. Likely the most reliable estimates of STAR efficiency
will result from these so-called embedding studies.

When STAR event reconstruction code operates on raw data, it performs
corrections (e.g. for gain variations), based on calibration factors
stored in a database. Since, ideally, the reconstruction code should not
\"know\" whether it is operating on real or simulated data, a further
requirement is that the slow simulator should access the database and
perform so-called \"inverse corrections.\" This requirement is perhaps
most important when one is performing embedding studies.

### Review of existing implementation - TRS 

Although the youngest software effort of the ones reviewed in this
section, the TRS package is relatively mature, maintainable, and overall
appears to be in good shape with regards to the description outlined
above.

The level of realism achieved should be sufficient for the most common
efficiency studies, and is on a roughly comparable level with slow
simulators from existing/publishing (EOS, E895, NA49) and future (ALICE)
TPC heavy ion experiments.

-   The top action item, which the committee recommends should be taken
    immediately, is simple inclusion (formal integration) into the
    existing chain (BFC) that is available and tested nightly.

This is the only way to identify problems and stimulate
feedback/evaluation from users other than the developers. Furthermore,
evaluation/testing of the clusterfinder (and to a lesser degree, the
fast simulator) is currently hampered by the absence of TRS in the
available chain.

> Further action item issues have already been identified (see below),
> the committee feels that none of them are showstoppers, and in
> particular, that inclusion of TRS in the chain should *not* wait until
> they are resolved.

-   Related to the above point is the issue of interfacing to the
    calibrations database. A real obstacle to evaluating the
    clusterfinder (see below) was caused by the reconstruction code
    correcting the \"data\" based on calibration constants from the
    database; the correct procedure would be for TRS to apply the
    inverse corrections based on the *same* constants from the same
    database. Integration of the database into STAR
    simulation/reconstruction software is a relatively recent
    development, but the handshaking is beginning to stabilize, for
    those packages currently in the standard release. The committee
    recommends that the TRS developers work with the database team to
    incorporate this interface soon after integrating TRS into the BFC.

```{=html}
<!-- -->
```
-   Also very high on the priority list is to identify a \"loving
    owner\" of TRS, who feels personally responsible for its
    maintenance, upgrades, and tuning. The people who have brought TRS
    this far have done excellent work, and this recommendation does not
    reflect poorly on them. It simply recognizes that there are other
    issues (other STAR projects, Ph.D. theses) that are pulling these
    people away from TRS.

While STAR can limp along for the short term (1-2 months) with a group
of several knowledgeable TRS folks who can provide a quick bug fix or
easy upgrade, the committee sees the need for a single person who will
become intimate with all its parts.

-   It is the understanding of the committee that not all of the
    \"hooks\" for the inverse corrections (mentioned above) are
    implemented into TRS. So that, even if the individual gains were
    available (see below), some code is still required to make use of
    them. The committee recommends that the important inverse
    corrections be identified (some discussion centered on whether
    individual gain corrections were important in STAR), and the
    appropriate code implemented.

```{=html}
<!-- -->
```
-   As mentioned above, performance bears on the utility of this
    simulation tool. At the review, there were several estimates of the
    CPU time to process a standard density event on an RCAS node; many
    seemed to agree that 20 minutes/event/machine was more or less the
    current status. If nightly test production of 40 events would
    include TRS, then, this would imply 13 computing hours for TRS
    alone.

> Appropriately, speed optimization has not been the main priority in
> TRS until now, and recent analyses of the code suggest that
> significant gains can be achieved without huge amounts of rewriting.
> The committee recommends that efforts in this direction be pursued at
> this point.

## TPC Fast Simulator

### Committee\'s understanding of generic package purpose 

As discussed above, the slow simulator is intended to mimic the behavior
of the STAR TPC detector (including readout electronics and DAQ), so
that the entire reconstruction chain (including calibration corrections
and clusterfinding) may be exercised. On the other hand, the fast
simulator is intended to mimic the integrated effect of the detector
*plus* the clusterfinder. Therefore, while the input is again GEANT
hits, the output in this case are reconstructed hits, in the same data
structures as are filled by the clusterfinder.

While one might hope for similar realism at the level of the hits, it is
recognized that the large performance boost in using the fast simulator
derives from a more simplistic parameterization of the underlying
processes. Hence, the fast simulator is intended more for
high-statistics exercises of downstream software. Very detailed studies
employing, for example, embedding techniques, are not foreseen.

Similar to the requirement discussed for the slow simulator above, the
chain downstream should ideally not \"know\" whether it is starting from
hits coming from (1) actual TPC + clusterfinder, (2) slow simulator +
clusterfinder, or (3) fast simulator.

### Review of existing implementation - TFS 

Overall, the TFS package is a mature, well-understood, and
much-exercised software tool. Almost every TPC-based result to date has
used it. The \"reality level\" (concerning topics such as track
splitting, particle identification (dE/dx) resolution) is generally
reasonable.

Some items which the committee believes deserve attention follow.

-   A main issue (which will be repeated later in the discussion on the
    tracker) is that TFS smears the GEANT-generated hits by some
    resolution, (which depends on crossing angles, etc), and then puts
    this resolution into the uncertainty field of the reconstructed hit
    table. In this way, the tracker can make \"intelligent\"
    outlier-rejection choices, and the chi-square value characterizing
    the goodness of a track fit can have some meaning.

The problem with this is that the clusterfinder does *not* provide
reasonable uncertainty values (this is discussed below). Thus, the
current TFS behavior does not simulate correctly the action of the
detector plus clusterfinder, and so violates the understanding of
package purpose.

> In addition, under the operating mode discussed above, users of the
> tracking code come to depend on \"knowing\" whether the upstream
> software is TFS (in which case the uncertainties, and chi-squares, are
> dependable) or the clusterfinder (in which case they are not
> dependable). This violates another point in our understanding of the
> package purpose, and may hamper full exploration (via simulation) of
> tracking issues that will arise with \"real\" data.

-   Flagging of merged hits: As a rough approximation of the effect of
    hit merging, TFS merges hits whenever the GEANT-generated hits are
    closer than some cutoff distance. This is reasonable. Since merged
    hits will have less reliable position information, and are unusable
    from the point of view of particle identification via dE/dx, TFS
    flags the hits which are merged, so that downstream software may
    treat them specially.

One wonders the degree to which this simulates reality. Certainly, in
some cases, the clusterfinder will be able to determine that hits have
been merged, and so can flag the resultant hit(s). However, if tracks
cross particularly close to each other, the clusterfinder will not have
this information; in this case, TFS is passing on information only
knowable to a simulator, violating the understanding of the purpose of
the package above.

-   Again concerning uncertainties, it is a bit surprising that the
    uncertainty in the drift direction does not depend on drift length
    in the simulation. Clearly, the dip angle dependence (which is
    accounted for) is the dominant effect, and for tracks originating at
    the TPC center, there is a strong (anti)correlation between drift
    length and dip angle. However, it was acknowledged during the review
    that a z-dependence should be implemented.

```{=html}
<!-- -->
```
-   It appeared odd that the position of the resultant (merged) hit was
    determined by a weighted mean of positions, in which the mean is the
    *width* of the hit. Naively, total area would seem more appropriate.

## TPC Clusterfinder/Hitfinder 

### Committee\'s understanding of generic package purpose 

The cluster- and hit-finding package (often referred to simply as \"the
clusterfinder\") is the first non-calibration/correction package in the
data reconstruction chain. It should interface with the TPC pixel data
produced by the DAQ (or a simulation of DAQ) and find the positions at
which charged tracks cross the TPC padrows. Generically, this is done by
looking for peaks in ADC counts in the 2-dimensional space of
pad-vs-time bucket, and then fitting the structures to obtain a
centroid. Deconvolution of overlapping peaks can be attempted.

These positions are given in two locally-defined dimensions: along the
drift and pad directions; the third direction is perpendicular to the
padrow and is inaccessible (indeed, undefined) at the clusterfinder
level. Typically, the information generated is a list of reconstructed
\"hits.\" Along with position determination, hit information from the
clusterfinder should have the total charge associated with the hit (for
particle identification), whether the hit is influenced by more than one
track (merging), and- ideally- the uncertainty in the hit position.
Characterization of the shape of the cluster is often useful downstream,
as well.

Due to its early position in the reconstruction chain, some calibration
tasks often get integrated into clusterfinders. These can include
channel-wise t~0~ offsets (which shift pixels in time by fractions of a
time bucket, and so cannot be incorporated into the pixel table) and
offline gain corrections (which can in principle be done on the pixel
table prior to clusterfinding). Constants associated with these
calibration tasks, as well as detector geometry, should be keyed in
externally (e.g. from a database).

Previous experience in TPC experiments leads to well defined
expectations on merging and resolution properties of the clusterfinder.
These are perhaps best documented in the book of Blum and Rolandi; the
characteristics and trends described there have been verified as well in
heavy ion TPC measurements EOS, E895, and NA49.

Less well-determined from previous experiments are expectations relating
to performance; in NA49, clusterfinding was significantly faster than
tracking, while in E895, the reverse was true. While it is something of
a technical detail, \"reasonable\" CPU performance is a requirement for
any package in the reconstruction chain.

A final point worth mentioning explicitly: Clusterfinders in these
experiments, as well as that of ALICE under development, also share a
common deficiency- despite significant effort to do so, none return
reliable uncertainties for the hit position. As a result, trackers in
these experiments generally ignore the uncertainties returned by the
clusterfinder, and replace them with a parameterization (sometimes by a
constant number).

### Review of existing implementation - TCL 

TCL is a relatively old and simple package that was largely left
neglected (except for frequent tweaks necessary to comply with changing
infrastructure) for some time, and then patched/tuned/appended as needed
for cosmic ray analysis or the addition of cluster shape
characterization.

Early simulation studies documented relatively satisfactory efficiency
and resolution (STAR Note 238). However, algorithmic improvements,
fixes, and hooks for calibrations have been added over the years. More
recent simulation-based evaluation studies have been hampered by the
erosion of TCL-specific evaluation tools (see below). However the
performance of the overall event reconstruction (essentially
clusterfinder & tracker) in \"real\" cosmic ray, laser, and RHIC
beam-gas events, in addition to the earlier simulation studies on the
unimproved code, provides some confidence that TCL is ready \"enough\"
for year-1 data.

-   The committee recommends that a serious effort go into CPU
    optimization of the clusterfinder. During the review it was stated
    that this has not been a top priority until now. On a
    low-multiplicity event, clusterfinding takes ∼25 times longer than
    tracking, a huge factor by the standards of any of the experiments
    mentioned above.

> Indeed, a timing profile performed just before the review revealed
> that a single geometry function called multiple times accounts for
> ∼85% of the CPU time in the clusterfinder; offline discussion
> indicates that reduction of the number of calls by at least an order
> of magnitude will be trivial.
>
> It appears clear that the time is right to perform these simple
> hotspot checks, and do simple optimization.

-   The committee recommends that more sophisticated use of currently
    existing STAR wide evaluation tools (in particular, the
    StMcEvent/StAssociationMaker) be developed for use with the
    clusterfinder.

> Historically, clusterfinder evaluation was performed via internal
> \"index tables\" and a \"shadow pixel map\" containing pixel-by-pixel
> information about GEANT tracks that contributed to the pixel. These
> methods have long ago been abandoned. While there was some discussion
> as to whether to revive them, we recommend applying the new tools.
>
> Since the new tools employ proximity tests to determine hit-wise
> associations, it is important that the slow simulator and the
> clusterfinder access the same database and perform the same
> corrections (or \"inverse corrections\" in the case of the slow
> simulator- see Sec. 5.1).

-   Currently, the methods used by the clusterfinder are somewhat
    simplistic. In particular, no true deconvolution of overlapping hits
    is attempted; instead, single-peak fits are performed on the pixels
    local to a peak in the pad-time bucket space. Also, while the peak
    *finding* is truly 2-dimensional, the peak fitting is performed
    one-dimensionally separately in the pad and time bucket space.

Other experiments have attempted more sophisticated techniques. For
example, the E895 experiment (which deals with higher hit density than
expected for STAR) began with the STAR clusterfinder, and incorporated
true hit deconvolution and 2-dimensional fitting (at a considerable
CPU-performance cost). At a considerably lower priority than the points
above, the committee recommends exploring these possibilities.

-   In light of the experiential fact that, without crossing angle
    information (available only at the track level), reliable position
    uncertainties cannot be obtained, the committee recommends not to
    invest effort in trying to calculate these uncertainties in the
    clusterfinder.

## TPC Tracker 

### Committee\'s understanding of generic package purpose 

Tracking software in an experiment like STAR is as important as any
detector subsystem, and its heart consists of the TPC tracker. There are
several different tracking approaches on the market, under evaluation,
and under development, many (or a combination) of which may be
appropriate for STAR. Here, we avoid the details, and simply state some
tasks that the TPC tracking package should perform.

Starting with a list of all reconstructed hits (or directly from pixels,
in some proposed approaches), the tracker should perform pattern
recognition to identify \"tracks,\" which are sets of hits all caused by
the same charged particle intersecting consecutive planes of the TPC
padrows. Either simultaneously with this, or in the same step, it should
fit the track with a well-defined track model (e.g. helix), and return
(at minimum) the following information: the 3-momentum and the
3-position of the particle at some point in its trajectory. The tracking
model should be sufficiently complete so as to allow extrapolation of
the track trajectory (e.g. to its closest approach to the primary
vertex). The principle \"output\" of the tracker, then, is a list of
tracks measured by the TPC.

In addition to the particle trajectory and momentum, tracks in the
returned list should carry reliable estimates of the uncertainties of
these parameters. Also, track information should include some idea (e.g.
via chi-square or confidence level) of the goodness-of-fit, as well as
quality-related topological information such as the number of hits on a
track.

Since conditions (B-field, position of the primary vertex, track
density) may vary, the tracker should be robust against reasonable
variations in the tracking environment.

The tracker represents the level at which many compromise decisions are
taken: maximal efficiency versus maximal purity, track splitting versus
track merging, etc. Naturally, these considerations must be made in the
context of physics analysis requirements, which this committee is not
designed to discuss in detail. However, one expects the tracker\'s
handling of these issues to be (1) well-understood, and (2) controllable
(i.e. changeable) within reasonable limits.

### Review of existing implementation - TPT 

TPT is among the most visible, discussed, and studied software packages
in STAR. The general algorithm is straightforward (not to say
simplistic), although many details (allowing for gaps, boundaries,
straight-line tracking for zero-field running\...) of the implementation
can be quite involved.

It begins by finding track \`\`roots,\'\' which are 3 hits on adjacent
padrows whose clusters overlap in pixel (pad-bucket) space (or, for the
inner sector, hits in a line directed at the center of the TPC).
Conformal mapping of hit positions and linear extrapolation
(follow-the-nose) are used to build longer \`\`segments\'\' from these
roots, and the segments are then reshuffled and extended to form longer
tracks. Finally, the track is fit with a 2-component helix (circle in
x-y and line in s-z) to extract track parameters.

Overall, based on simulations, general experience of robustness over the
past several years, and exercise through cosmic ray and commissioning
runs, TPT is considered to be \`\`ready enough\'\' in terms of
efficiencies, purity, etc. to start attempting physics analysis in STAR
using its output. The committee finds that some points still deserve
attention, however. Especially the first one listed should be addressed
as soon as possible, hopefully before data.

-   Hit-position uncertainties are crucial for good fitting and momentum
    determination, and especially for meaningful goodness-of-fit
    estimates. Most of the tracker exercises have been carried out using
    the fast simulator TFS, which does provide reliable uncertainty
    estimates. However, as discussed above, the clusterfinder does not
    (and likely never will) provide reliable estimates of the
    uncertainty in the hit position. The implication for real data is
    that chi-square (and other) quality variables, upon which downstream
    software relies, will be meaningless, and that inefficiencies/biases
    may to develop for large rapidity, low-p~⊥~ tracks.

The position uncertainties may be reliably parameterized in terms of
local track parameters (i.e. crossing angles and drift length), which
are known at the level of tracking. The committee feels a top priority
must be to generate hit-wise position uncertainties based on the local
track parameters in all cases- i.e. even for the fast simulator.

-   In the TPC tracking presentation, a pattern recognition (root
    formation) bias was discussed; the magnitude of the problem had not
    been fully evaluated. This could lead to low efficiency or enhanced
    ghost track probability for low p~⊥~ (tracks not reaching row 16)
    particles, if the primary vertex is not at the center of the TPC. It
    was stated that the route to elimination of this potential problem
    is understood, and a fix would take about 1 week\'s work. Instead of
    further evaluation of the magnitude problem, the committee
    recommends implementing the fix.

```{=html}
<!-- -->
```
-   The solution to the above point involves a rapid estimate of the
    position of the primary vertex. Since this position is useful to a
    number of reconstruction packages, the committee recommends that the
    estimated vertex position be made available to the \"outside world\"
    in some standard way.

```{=html}
<!-- -->
```
-   The committee perceives that a rather small group of people is
    simultaneously *developing/maintaining* the tracker as well as
    *evaluating* it, and recommends that much more evaluation be done by
    STAR collaborators outside of this group. This will produce more
    educated \"consumers\" of the tracker output; many of these
    consumers will be performing physics analysis, and should be
    intimate with relevant details of the tracker\'s behavior. Also, it
    should generate a greater volume of analysis-relevant feedback.

```{=html}
<!-- -->
```
-   In much of the evaluation discussed during the review, tracker
    evaluation centered largely on the correspondence between the
    reconstructed track, and the corresponding Monte Carlo track which
    was its *best match*, according to the number of hits in common. In
    the terms used during the review, reconstructed/generated track
    pairs with the highest \"qfact\" were mostly considered. The
    committee worries that evaluations focussing on the largest-qfact
    matches may miss important information on ghosts and momentum
    resolution, and thus recommends that further evaluation efforts not
    center as exclusively on the largest-qfact matches. These \"further
    efforts\" may provide a natural starting-point for the \"external
    evaluators\" referred to above.

```{=html}
<!-- -->
```
-   A specific technical comment related to evaluations: A conformal map
    is currently employed in the pattern recognition step of the
    tracking. For performance reasons, the hit uncertainties are not
    transformed. Conformal maps are quite nonlinear near the origin
    (inner padrows), and biases or hit-loss could occur there. The
    committee recommends a careful evaluation of the distribution of the
    innermost padrow of the first correct hit on a track, to probe for
    this potential problem.

```{=html}
<!-- -->
```
-   It was discussed briefly during the review that the tracker might
    run a \"second pass\" with looser cuts, which could be more
    efficient for non-primary or spiraling tracks. Also, various
    switchable specialized routines have been implemented, which try to
    merge spiraling tracks (e.g. electrons) for specialized physics
    analyses (e.g. photon reconstruction). While these issues were not
    discussed in detail in the review, the committee makes the simple
    recommendation that the effects of these specialized routines on
    \"standard\" analyses be carefully evaluated, before switching the
    routines on by default.

# SVT Tracking

The committee acknowledges the excellent progress made by the SVT (SDD
and SSD) software group in the development of SVT tracking software. The
committee recognizes in particular the outstanding efforts of Helen
Caines in the coordination and implementation of tracking software. We
summarize below our views on the different packages currently developed
and make recommendations for future packages implementations.

## SRS -- SDD Fast Signal Simulator

The simulations presented were based mainly on the SRS signal simulator.
K. Wilson developed this simulator while at Wayne State University. The
simulator takes GEANT hits as inputs and produces simulated SDD hits
accounting for diffusion, Coulomb repulsion, noise, as well as finite
crossing angles of the particle through the silicone wafers. It also
performs hit merging whenever GEANT hits are found within a specific
radius of confusion.

Although great care was taken by Wilson to design and implement the SRS
simulator so it reflects the actual detector performance in terms of
resolution and merging, it is nonetheless desirable to explicitly verify
whether the SRS parameters used in the tracking simulations are
appropriately implemented and set. An analysis based on the E896 data,
or laser test performed on the bench might be appropriate for such
verification.

## SSS -- SDD Slow Signal Simulator

The slow simulator is currently under development at Ohio State by a
graduate student under the guidance of Helen Caines. A C++ code is being
developed based on earlier works by Reed, Rykov, and Pruneau. The
simulator is not yet in a state such that it could be included in the
STAR reconstruction chain.

The committee would like to emphasizes that an actual simulator of the
digitized SDD signals is expressly needed to perform truly realistic
simulations of the detector performance and, in particular, to optimize
the cluster finder. Although the simulation of digital signals is not as
critical for the SVT as it is for the TPC because the expected occupancy
of the SVT is much lower than that of the TPC, the slow simulator is
nonetheless needed to properly account of noise effects (which might be
more significant in the case of the SVT) and for merging clusters which
can only be handled very approximately with the SRS package.

On the technical side, the committee recommends that the C++ SVT slow
signal simulator be modeled on the TRS packages. Specifically, we
suggest that a designed using clear separation of the different stages
of signal generation, and making use of abstract interfaces to delineate
these different stages might enable a flexible and powerful simulation
tool.

Once the SSS package implementation is completed, we further recommend a
detailed comparative analysis of the resolution and merging be carried
to properly tune the parameters of the simulator. Given the time
required to complete the C++ implementation, we expect that the code
shall be completed when new SDD data are available from the seven wafer
ladder positioned in STAR for the summer run. It should thus be possible
to perform a comparative analysis of the simulator performance based on
the new data.

Once the performance analysis is completed, the simulator shall then be
included in the full STAR simulation/reconstruction chain.

## SSD Simulators

The Nantes group has taken responsibility for the design and
implementation of the SSD simulator, the SSD hit finder, and a new
tracker, which performs an outside--in search of SSD and SDD hits based
on seed tracks reconstructed within the TPC. The simulators are
discussed in this section whereas the hit finder and tracker are
discussed in subsequent sections.

The Nantes group has developed a fast simulator of the SSD, which
enables a transformation of GEANT hits within the SSD into strip hits as
actual signals will be readout from the SSD. The algorithm and
techniques used within the simulator were very briefly discussed by
Hypolite. The methods used in the implementation of the simulator appear
quite reasonable although a longer presentation might have been needed
to fully discuss the details of effects of variable crossing angles,
finite signal-to-noise, and charge sharing between adjacent strips. The
committee recommends the authors of the simulator should produce a
"long" write-up on the simulator to describe it in better details.
Efforts should also be done to adapt the existing code to the most
recent STAR software convention and standards so it can be readily
incorporated within the simulation and reconstruction chain.

## SCL - SDD Hit Finder

The hit finder developed for the STAR SVT is based on code that was used
in the analysis of the E896 SDD data. The code algorithm was clearly
presented by H. Caines. It is however not clear whether the cluster
finder code is currently in a state such that it can readily be used in
the STAR reconstruction chain. In particular, it is the understanding of
some members of the committee that the cluster finder used in E896 was
tailored to the specificities of the E896 data (baseline shifts, noise,
etc). One thus wonders whether the STAR version of the code carries
those specificities. One may also envision that the actual SVT data will
also have "features" of its own. The STAR SVT cluster finder will thus
also require to be fine tuned.

The committee recognizes that Selemon Bekele, from OSU, currently has
the responsibility for completing the deployment and maintaining the
cluster finder. We emphasize the urgency of deploying a STAR/SVT version
of the code.

## SSD Hit Finder

The Nantes group developed an interesting SSD hit finder which uses the
charge deposition on U and V strips to successfully identify multiple
hits topologies as well as the simple single hit per strip topology.

In view of the limited time allocated to this presentation, many
interesting details were left out concerning the performance of the hit
finder. The committee was nonetheless impressed by the very large
efficiency and purity achieved in the reconstruction. Such a high
reconstruction efficiency and purity result in parts from the very low
detector occupancy for canonical HIJING events. The committee notes that
it would be prudent to consider the reconstruction efficiency and purity
for much larger multiplicity events. One should also clarify the role of
the finite signal-to-noise ratio in producing spurious random hits that
might cloud or complicate the track reconstruction. As in the case of
the SSD simulator, we also recommend a "long" write-up be produced by
the authors of the finder to properly document its algorithm, as well as
its performance. It would be advisable, in particular, to fully document
the contribution of the 1-1, 1-2, and 2-2 topologies to the
reconstruction efficiency and purity in greater details.

## Track Finder

The SVT currently uses a standalone tracker based on the STK and SGR
packages to accomplish track reconstruction. A TPC track to SVT point
track-finder is also being developed by the Nante group. We review these
separately below.

### SVT Standalone tracker

The standalone tracker uses a combination of a so-called "grouping"
technique and a follow your nose approach. The grouping code, called
"grouper", is used in a first pass to identify the high momentum tracks.
Hits associated with tracks are tagged as such and become unavailable
for further reconstruction passes. The follow your nose tracker is then
run as a second pass to identify lower momentum tracks as well as tracks
which do not originate from the main interaction vertex (i.e.
secondaries).

The "grouping" technique amounts to identifying 3-4 hits clusters in the
hits phi-theta representation-space. The technique is ideal for a fast
identification of high momentum tracks which, typically, form tight
clusters in the phi-theta representation space.

The follow your nose tracker is based on a more traditional approach
where hits are found successively by extrapolation of track segments
starting from the inner layer and searching for matching hits outward.

The committee recognizes that (helix) track finding based on a set of 3,
or 4 points is clearly not very well constrained. Such a weak constraint
can lead, in a standalone mode, to the reconstruction of a large number
of ghost tracks. To be more specific, the identification of well formed,
helicoidal tracks based on 3 hits solely relies on the chi-square of the
phi-z fit. This fit is a linear regression with 3 points, and 2 fit
parameters: the straight line is not very well constrained. This means
that hits can be assigned to many tracks with similar values of
chi-square, and it is practically impossible to distinguish the properly
reconstructed tracks from the ghosts. This thus explains why so many
ghosts are actually found in the tracking simulation presented by H.
Caines. We note however that in spite of the weak constraints mentioned
above, one can nonetheless tailor the reconstruction code to minimize
the number of ghosts at the obvious expense of reducing the
reconstruction efficiency. One should stress that data with a rate of
50% ghost tracks are quite likely to be of limited use for physics. The
committee thus strongly recommends that a careful analysis be conducted
to determine the inter-relation between the number of ghosts and the
reconstruction efficiency. The emphasis of this analysis should be on
secondaries which constitute "la raison d'être" of the SVT.

The committee also notes that the treatment and propagation of errors is
currently not handled in the optimal way. Clearly, the use of two 2D
fits (circles in x-y and straight lines in phi-z space) rather than a 3D
fit does not lend itself to an optimal treatment. Although such a
simplistic approach was sufficient to assess the performance and useful
of an SVT addition to STAR back in the days of the STAR CDR, a better
fit approach which account for full error matrices, and multiple
scattering within the detector, is clearly desired. It is clear however
that track fits based on 3 or 4 points may not practically be amenable
to more sophisticated treatments: standalone tracking and fitting,
except for the lowest momentum of interest, does not appear a very
viable long term strategy for STAR and SVT tracking. (More below on
this).

### TPC Track to SSD/SVT Points Matching (vector to point)

The Nantes group has begun the elaboration of an outside-in tracker with
track seeds selected from the track segments reconstructed in the TPC.
The tracker is built as a multi-pass algorithm which proceed to first
match high momentum tracks from the TPC with SSD and SVT hits, and
iteratively uses lower momentum tracks to match as many points of the
SSD/SDD as possible.

The results resented by L. Martin were quite encouraging. On the onset,
this tracking technique appears extremely promising. The committee
however wishes to formulate few remarks on the algorithm used in the
tracker.

-   We strongly recommend that the association of hits to the TPC tracks
    should make use of a tree structure: i.e. initially, SSD/SDD points
    should be allowed to be associated to more than one TPC tracks so
    one can evaluate which of the associations has the best quality
    rather than using, as in the analysis presented at the review, a
    "first tested gets the track" approach. One should however be
    careful with the tree-build algorithm so the tree size does not
    explode in size: not all associations may be built -- a number of
    criteria must be used to avoid uninteresting associations. (Note
    however that in a fully optimized tracker, such criteria are likely
    to evolve as one proceeds to find lower momentum tracks as well as
    secondaries).

```{=html}
<!-- -->
```
-   The multi-pass approach starting with the highest momentum is
    excellent as it allows a "safe" clean up of a large fraction of the
    SSD/SDD points. One should however make sure that the TPC tracks are
    not subject to random associations with SSD/SDD points. To that
    effect, it is recommended that early passes should include the main
    vertex i.e. one should try to associate SSD/SDD points which fall
    near/on an extrapolation of TPC tracks leading to the main vertex.
    This insures that the easiest tracks to be found, the high pt
    primary tracks are properly assigned and given priority in the tree
    based search of hit associations.

```{=html}
<!-- -->
```
-   The TPC tracks should be first sorted in order of decreasing
    momentum. The search can than proceed from the highest momentum to
    the lowest without any particular biases. We suggest that the use of
    track groups based on momentum intervals as it appears to be
    currently done may lead to pathologies which could be difficult to
    understand while it appears a lot safer, and just as simple, to
    systematically proceed from the highest to lower momenta based on a
    sort.

```{=html}
<!-- -->
```
-   The search algorithm should include the possibility to turn off a
    layer of the inner detector: i.e. on the onset, the tracker should
    be built to accommodate either a three-layer SVT, or an SVT+SDD four
    layer detector. This way, the tracker may be used during year one,
    with the SVT alone, just as well as in year two.

```{=html}
<!-- -->
```
-   The committee acknowledges the effort to explicitly account for
    scattering on non-active materials within the detector. We however
    recommend that a Kalman filter approach would readily solve the
    problems involved in taking scattering into account while the re-use
    of existing Kalman code, or at the very least modeling new code on
    existing Kalman codes could significantly speedup the implementation
    and deployment processes. The Kalman filter technique also offers
    the advantage of an optimal treatment of hit position errors.

```{=html}
<!-- -->
```
-   The committee also recommends that in the evaluation of the
    algorithm, one should test the relative merits of various pre-sort
    on TPC track quality (in addition to the momentum sort). Quality
    sorts might be based on the track length (i.e. number of hits on the
    TPC track segment), chi-square, etc.

## SVT -- TPC Track Matching (Vector-to-Vector)

The results presented on SVT and TPC track matching reflect the
difficulty of the task and need further attention. Members of the
committee suspect the poor matching performance may in part result from
a (i) a non-optimal choice of the matching surface (i.e. the surface
where both TPC and SVT tracks are extrapolated for the purpose of
attempting position and direction matches), (ii) the limited momentum
resolution of the SVT, (iii) improperly accounted for scattering effects
in the inner layers (the radius of low momentum tracks changes has they
reach outer layers of the SVT and the TPC -- this entails a bias in the
association of SVT tracks to those of the TPC; (iv) inappropriate or too
stringent cuts used in the associations.

The committee suggests that if the SVT software group wishes to pursue
the current vector-to-vector matching approach further, a significant
re-write of the code in C++ might be in order. The algorithm should
enable many-to-many associations: one should first build all plausible
associations of SVT tracks to TPC tracks (in C++, this amounts to
building a multi-map). One should then proceed to fit the tracks and
sort them in order of decreasing chi-square. The best matches are thus
trivially obtained from the sorted list: only then should one require
one-to-one matches and tag the track segments as matched. It might be
also be appropriate to pre-sort the TPC tracks based on quality (number
of points or chi-square) as well as momentum in order to guarantee that
the best tracks are matched first and removed from the set of match-able
tracks.

## Generic Comments on SVT-TPC Matching, Errors, and Performance Evaluation

The strength of the SVT lies in its capacity to provide a very accurate
primary and secondary vertex positions, whereas, its performance as a
standalone tracker, is intrinsically limited by the small number of
layers, and the sizeable multi-scattering effects. The absence of
a-priori knowledge about the primary or secondary nature of the tracks,
in particular, further complicates the task of SVT tracking. The
somewhat limited matching efficiency results presented are no doubt the
best indicator of the difficulty of the task at hand.

The committee would like to stress that the vector-vector matching
approach, as presented, is obviously limited in its usefulness because
of (i) the rather limited efficiency, and the large ratio of false
associations obtained, and (ii) the fact that the vector-to-vector
approach, as used, may be intrinsically inadequate (or at the very least
incomplete) for the treatment of secondaries given that by their nature,
secondaries do not always produce hits in the inner layers of the SVT.
We thus propose that the SVT group (including Nantes collaborators)
while maintaining an optimization effort of the existing standalone
tracker and matcher should invest seriously

in the development of a vector-to-point matcher in the spirit of the
work presented by the Nantes group. We stress that in terms of CPU
usage, and track recognition time, the use of separate trackers for the
SVT and TPC does not seem an optimal approach given the combinatorics
involved in first searching for tracks in both SVT and TPC, and then
attempting to connect these together to form longer tracks covering both
detectors. An outside-in road finder using simultaneously both SVT and
TPC hits should offer easier track recognition and reconstruction
capabilities (inclusion of SVT points better constrained), and most
likely a lower CPU usage.

We re-iterate that a proper treatment of the position errors is urgently
needed in order to permit a reliable evaluation of the track quality. We
also recommend a Kalman filter based method for track fitting and
quality assessment.

# Global Tracking

The committee would like to acknowledge the efforts of Spiros Margetis
in establishing a credible global reconstruction. The committee
recognizes the fact that the tasks of global reconstruction in year-1
and all future years are quite distinct and therefore we chose to
discuss the relevant issues in that order.

## Year-1 Global Tasks

In year-1 global reconstruction provides the following: track re-fitting
in the TPC on the basis of a Kalman filter/fitter method, reconstruction
of the event vertex, track re-fitting with the vertex on the basis of a
Kalman filter/fitter method, PID information from all subsystems, TPC
alignment on the basis of tracking, pre-analysis code for kink and v0
finding in the TPC, write programs for the DST output. These tasks are
well addressed by the existing code.

Tasks that were not sufficiently addressed for the year-1 physics
program are the track extrapolation to RICH and EMC. Spiros stated that
the tool to extrapolate exists, but no results were shown (action item).
We recommend in this context to store position and tracking parameters
at the first and the last point in the TPC (using the Kalman fitter).

Regarding the Kalman fitter program, the actual improvements on the
physics have to be better documented. The program should not only be
used as an application for V0 finding cuts, but also as a generic
fitting program. The improvements in the track errors were nicely
documented, but they should also lead to an improvement in momentum and
energy resolution at momenta higher than 300 MeV/c. Presently the TFS
errors are used and we believe that switching to the slow simulator will
make the error improvements more realistic.

Work on the Kalman fitter should include the primary vertex and thus
requires a material propagator program (e.g. GEANE) that allows the
inclusion of effects based on the IFC, gas, and beam pipe material.
GEANE seems to run fast, but there might have been mistakes in the way
the program was used, which documents that the material propagation
studies are still in the early stages and thus have to be reviewed in
the future after the program has been established.

The primary vertex finding program seems to perform well, but it seems
to also cause some problems during the running of the BFC. Thus we
recommend to re-write the code and make it more stable. Tracks should be
weighted on the basis of the multiple Coulomb scattering and the
performance has to be optimized in particular for the year-2
configuration. Presently the improvements from year-1 to year-2 are only
a factor 2, which is in contradiction to the vastly increased impact
parameter resolution when including the SVT.

## Year-2 and Year-3 Global Tasks

For a detailed discussion of the two TPC-SVT matching approaches
developed in parallel, i.e. track-to-track vs. track-to-point, we refer
to section 6.6.

The tasks of the global reconstruction in year-1 and year-2 are very
different. And if the SSD will not be available in year-2 (which is very
likely), then the year-2 tasks will be different from year-3 tasks.

For year-2 an execution sequence has to be established that defines the
matching procedure or procedures between SVT and TPC. For year-3 this
code has to include the SSD.

For any kind of matching (vector or space point) we recommend to
evaluate the radius distribution of the innermost correct point on every
TPC track to evaluate the gap between TPC and inner tracking and thus
estimate the extrapolation.

The TPC track to Silicon space point matcher as presently developed by
the French groups should be finalized (within two months) and tested in
both configurations, with and without the SSD. The code has to allow
track tree formation (hit sharing) in the SSD. Also, material
dependencies, e.g. dip angle, might have to be taken into account.

We also recommend that the SVT/SSD groups be charged with working out
the details of the two matching approaches (track to track, track to
space point). It should be the responsibility of the inner tracker to
connect to the TPC, not vice versa. These programs should then be
integrated into the global reconstruction for a global re-fit.

## Manpower

We believe the group is seriously understaffed and fully agree with the
view of the Project Leader that at least 2-3 more full time people to
work on (global) tracking are needed in the near future to accomplish
the tasks.

# Future Planning

In his final remarks, Spiros Margetis in his position as Offline
Reconstruction Leader, presented plans for further developing, improving
and evaluating the tracking software. He distinguishes between projects
that can addressed during the next few months (short-term) and long-term
projects which, although not being of high priority for year-one
running, need to be planned and organized as early as possible in order
to succeed. In the following we comment on the long term planning only
since many of the short term issues were already covered in the previous
sections. In general the committee recognizes the short-term plans as
reasonable, especially since they address problems that are also part
(subset) of our findings.

## Long Term Plans

### Committee\'s understanding of proposed plans 

The plans presented to us include the development of a new modular TPC
tracker based on Kalman techniques. The R&D efforts as well as the
implementation is conducted and performed by a dedicated group that is
not in place yet. In addition the plan foresees to develop and use
Kalman based propagator tools for global tracking and, depending on the
outcome of the assessment tests, new improved tracking/matching
algorithms. The intention is to provide a uniform environment where
tracking algorithms can be tested, and which will facilitate the
extension of the TPC tracking into the SVT.

### Comments and Recommendations 

In general the committee welcomes the plans as presented, although it
feels that the detail of information available is not sufficient to
fully understand their implications. This is in part due the fact that
the reconstruction group itself is still reflecting on these issues and
that it has not yet finalize their detailed plans. We therefore give the
following recommendation in the hope that they will help to direct
future efforts. Please note that we are **not** recommending a specific
approach or technique but rather suggest a scheme on how to possibly
approach and organize the effort.

-   The Reconstruction Project Leader should officially form an R&D
    group which aims at developing an improved and coherent tracking
    approach incorporating all tracking detectors.

-   It should be lead by an experienced (senior) person with sufficient
    insight in the matter.

-   The group should be open to talented scientists with sufficient
    programming skills who are willing to devote a considerable amount
    of time into the effort. We estimate the need for at least three
    persons over the period of at least one year.

-   Persons involved in the current tracking efforts should be fully
    integrated. Even if they do not wish to play an active role, it has
    to be assured that experiences gained during the past years are
    incorporated into the new effort.

-   It seems advantage to work in close collaboration with experiments
    facing similar problems (e.g. ALICE, ATLAS, BaBar) thus taking
    advantage of their experience, findings, and (possibly) existing
    code.

-   The *scope* of the effort should be well documented and a set of
    milestones should be defined precisely: A detailed text should be
    prepared, describing the milestone and the date of completion.

```{=html}
<!-- -->
```
-   A person responsible for the milestone must be designated.

-   An estimate of the manpower and required programming skills must be
    given.

-   The criteria for successful completion of the milestone must be
    clearly established.

-   Consequences of failure must be indicated.

-   The committee recommends that the group does not focus initially on
    *one* approach only but rather investigate alternate techniques
    before making final decisions.

-   Once the group agrees on a specific approach their findings should
    be presented to a larger audience for review before the code gets
    implemented. A document should be written which explains the
    proposed concept and structure for the software.

All efforts have to be balanced vs. the need to maintain and, where
possible, improve the current implemented tracking software, i.e. any
new R&D efforts should not jeopardize current accomplishments. If
possible, new algorithmic ideas should be tried out in the current
framework before a major investment in manpower is dedicated to them.

# Appendix

## Agenda of the Tracking Review Meeting

**Thursday May 4, 2000**

1.  Reconstruction overview, *Spiros Margetis*

2.  TPC: overview, *Iwona Sakrejda*

3.  TPC response simulator, *Brian Lasiuk*

4.  Cluster/Hit finding, *Raimond Snellings*

5.  TPC tracking, *Iwona Sakrejda*

6.  Cosmic test results, *Eric Hjort*

7.  Evaluation tools, *Peter Jacobs*

8.  SVT: Resp. sim./Cluster/Hit finder, *Helen Caines*

9.  SSD: Resp. sim./Cluster/Hit finder, *Boris Hippolyte*

10. SVT-alone tracking, *Helen Caines*

**Friday May 5**, **2000**

11. Global: Overview, *Spiros Margetis*

12. TPC track to SVT track matching, *Helen Caines*

13. TPC track to SVT point tracking, *Lilian Martin*

14. Global refit using Kalman/Implications to V0 physics, *Al Saulys*

15. Event vertex finding and primary track tagging, *Lanny Ray*

16. Track extrapolation/Primary fitting, *Lee Barnby*

17. Short/longer term plans, *Spiros Margetis*

18. Preliminary report, *Thomas Ullrich for the Review Committee*