Hi again,
On Wed, 27 Sep 2000, Ian Bearden wrote:
> Where the track intersects a given TOF should be a property of the track. Then
> the PID can look at
> each track in the event and see which track comes closest to each hit in the
> TOF. Thus, the time of flight
> of the track comes from the PID, but the intersection of the " global" track is
> purely geometric and only depends
> on the plane of the TOF, not slat. If our resolution is anything like what we
> expect, the projected position of the
> track onto the plane of the TOF will be better than the TOF can determine that
> position.
You're right, the intersection with the TOF plane is a property of the track.
This TOF intersection point (as other "important points" along the track, for
instance the vertex plane intersection point) could be stored as BrVector3D
data members of the track, for easy distance calculations. As it is now, some
significant points (e.g. magnet entrance and exit points) are stored as single-
coordinate Double_t's (x,y in BrMRSTrack and BrFSTrack, and x,y,z in BrFFSTrack.)
The PID module (or any piece of code that knows about both the TOF geometry and the
global tracks) could loop over all tracks, calculate geometric intersection
points between track and fixed TOF BrPlane3D, and store as part of the track.
I see that the BrFFSPid and BrMRSPid now (in MatchHitTrack()) for each global
track creates nHit (no. of TOF hits) BrPlane3D objects and calculates nHit
intersection points.
> I'm trying to implement the (at least a) "real " vertex into
> BrFFSTrackingModule.
How do you plan to implement it? It should be done in a uniform way for all
the global tracking modules. The "Oslo" very preliminary additions to
BrMRSTrackingModule are (probably not the smartest approach possible!)
It assumes that the BrVertex is located in the event node also containing
the local BrDetectorTracks.
___________
Data member:
Bool_t fUseActualVertex (with Set() and Get().)
Method:
TrackToVertex(BrVertex* );
In Event():
BrVertex* vertexdata = 0;
Bool_t dummyvertex;
if (fUseActualVertex){
vertexdata = (BrVertex*)InputNode->GetObject("VtxData");
}
if ((!vertexdata)||(vertexdata->GetVertex_found()==0)){
// construct vertex at nominal interaction point, set dummyvertex=kTRUE
...
}
TrackToVertex(vertexdata);
In TrackToVertex(vertexdata):
// Transform global vertex into BrVector3D in D5 local system, construct
// Br3DPlane through vertex and with constant local z, and find
// intersection points as usual.
(Similar additions in BrTrackFinderBase, for the primary / secondary calculation.)
_______________
Typical vertex misses for "primary tracks" as classified by the eye, is 1 cm
or less (Bjørn is working on a note on preliminary tracking efficiencies and
vertex miss distributions -> primary / secondary ratios.)
> As I see it, this is
> absolutely necessary even to do calibrations in the FFS. It is not so critical
> in the MRS, but I guess we
> never really want to look at events for which we do not have a "good" vertex.
I agree, probably TPM1 vertex availability should be checked before global tracking
is attempted at all. Using a dummy vertex (as in our test version) is of course
a stupid and dangerous approach for PID and primary / secondary classification!
Maybe the BB / ZDC vertex would allow us to calculate a "good enough" track length
for MRS PID (at least in 90 degrees) but one would not have a reliable x vertex miss
for cutting on secondary tracks.
Trine
This archive was generated by hypermail 2b29 : Wed Sep 27 2000 - 12:00:20 EDT