Trine Tveter wrote: > 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. > 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. In this case, the track "knows" how long it is. It is true that this will give problems if a particle decays between Tx and TOFx, but 1) this should only be a small percentage (even for low-p Kaons in MRS) though I don't know what this percentage is, and we can't reconstruct these anyway. 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. > This needs to be done, and soon! We are working on it here, but have not come up with any super-genius ideas yet. > > 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. > I'm trying to implement the (at least a) "real " vertex into BrFFSTrackingModule. 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. hat 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. > I think such events are of rather limited usefulness. Any other opinions > > Just some naive thoughts from BRAHMS' northeastern outpost, > > Trine Trine, I really wish you hadn't said that! If your comments are naive, mine must be...actually I'd rather not think about. Cheers, -- Ian-------------------------------------------------------------------- | I.G. Bearden | | Niels Bohr Institute Tb 3 email: bearden@nbi.dk | | Blegdamsvej 17 phone: (+45) 35 32 53 23 | | København Ø FAX: (+45) 31 42 10 16 | | Danmark | ----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Wed Sep 27 2000 - 10:15:45 EDT