Hi,
On Tue, 26 Sep 2000, Flemming Videbaek wrote:
> Comments on MRS tracking
(long, intelligent and well-structured comments snipped.)
I agree with Flemming that it's unnecessary that each global track class
has its own (duplicated) code for calculating helix pathlength. The most
natural place for doing the helix part would IMHO be BrModuleMatchTrack.
In that case one approach to full path length calculation could be:
- let the BrMRS/FFS/FSTrackingModule calculate distance from vertex
(intersection with vertex plane) to entrance point into first tracking
detector, as a part of BrMRS/FFS/FSTrackingModule::TrackToVertex().
- then let the BrMRS/FFS/FSTrackingModule add known bits and pieces,
computing the track length from vertex to a specific point on the track
(e.g. exit point from last volume before the TOF detector), which could
be stored as a data member in the spectrometer track.
- The PID module could then fill in the last piece of track length up to
the TOF hit point.
A related issue that hasn't been discussed much so far (at least not on the
general lists) is the introduction of a real main vertex, for instance
as found by the BrTPMCluster/TrackVertexModule, into the
tracking / PID chain.
There are several ways to transfer the vertex information to the tracking /
PID chain with respect to data flow / data structures, and we should probably
agree on a uniform and economical way to do this. Some of the possibilities
are:
- The global vertex (nominal for the time being) is already used by
BrFS/FFS/MRSTrackingModule for calculating the vertex miss for spectrometer
tracks projected back. One could let the global tracking module look for
a BrVertex object in the appropriate BrEventNode as a part of the Event()
method, and use the vertex as an argument in TrackToVertex(BrVertex* ).
(An "Oslo" version of BrMRSTrackingModule uses this implementation for
test purposes - not necessarily the best one.)
Alternatively, the module could have a BrVertex* pointer and receive the
vertex by a public BrFS/FFS/MRSTrackingModule::SetVertex(BrVertex* ) function
called in application code.
- Similarly, the PID module could look up the BrVertex in the event node, or
get it by a SetVertex(BrVertex* ) call, and give the vertex object as
an argument to BrFFSTrack and BrMRSTrack::PathLength(...) (as suggested
in the present version of BrSpectrometerTracks.h)
This boils down to a question of which modules / data objects should / need to
know about the global vertex. For some purposes, it might be useful to
relate also local tracks to a global vertex (an "Oslo" version of
BrTrackFinderBase projects BrDetectorTracks back to vertex to look at
the primary / secondary ratio in TPM1.)
Then there are also questions of the vertex-using algorithms:
The track path length is calculated using the intersection point between
the track and a "vertex plane" as the track start point. What is the
best way to define this vertex plane when taking into consideration that
the path length is to be used for PID purposes? I see that the present
version of BrFSTrackingModule and BrFFSTrackingModule use the global z=0
plane (perpendicular to beam line) while BrMRSTrackingModule uses the plane
through the nominal vertex (0.0,0.0,0.0) perpendicular to the D5 local
z axis. Apart from a "globally fixed" or "spectrometer fixed" plane,
one could also use a plane through vertex perpendicular to the individual
track.
What should be the policy for events where no high-precision vertex is
available from any of the BrTPM...VertexFinders (insufficient data for
vertexing for less central events, or poor quality of the vertex
determined)? A BB / ZDC vertex might not give the precision needed
for PID, particularly not for high-momentum particles in FS, while
the track intersection with the global yz-plane might be good enough
for MRS in 90 degrees.
Just some naive thoughts from BRAHMS' northeastern outpost,
Trine
This archive was generated by hypermail 2b29 : Wed Sep 27 2000 - 09:13:41 EDT