Trine Tveter wrote:
> 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.)
>
When I started looking at this, there were methods to Set and Get Entrance and Exit
points, but
these methods werre not used. I used them, but did not change the variables to
vectors. My reasoning at
the time was that these are not vectors, but points. Still, it is probably better to
use BrVectors.
>
>
> 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.
>
>
I thought it should go into the (f. eks.) BrFFSTrackingModule in place of what I now
call WrongVertex.
A few minutes thought convinced me that this is probably not the way to go. I guess
what we should do
is calculate the vertex very early in the processing and add it to the event node and
then in subsequent modules
read the vertex from the event node. Which is what the Oslometode does, I guess. Of
course, the implementation
would then be the same 'automatically' since the event 'knows' its vertex and this
info just has to be extracted
by the given tracking module (or the tracking package, as CHC would have it.).
___________
>
> 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.
>
Yes, the WrongVertex has now outlived its usefulness, I suppose. It may be possible
that BB/ZDC gives a
good enough vertex. How many tracks must go through TPM1 before you can call it a
vertex? Or, without
paraphrasing Dylan: what is the probability that there is a track through the MRS from
an event for which
it is not possible to reconstruct a vertex using TPM1? I guess this probability is
rather small, unless the
problem is too many hits/tracks in TPM1.
>
> Trine
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 : Thu Sep 28 2000 - 01:36:43 EDT