[Brahms-dev-l] trackvertex

Included are some of my thoughts on track vertex, and track length. Please comment for discussion to finalize this



flemming



Comments on track vertex and projection.

 

i)                     I reviewed how things are being done, and it is a bit of a mess, ending up with different meaning of variables depending on the methods used in algorithms. E.g. when the bbvtx is used the trkVtx is the difference to the projected track on the plane perpendicular to the Bbvtx, while the z is that of bbVtx. In the case of not using bb (as e.g. for pp, but possibly also for light ion etc it is the projected Z to the beamline (some how misleading call BeamTrackVtx. The pathlength is calculated from bbVtx or from the projection. (*)

ii)                   W/o having to rewrite the tracking in a consistent way my preference would be the following, meant to make clear the distinction between properties of the track, and properties of the vertex.

·         Calculate the total tracklength from a vertex given by a global detector (Bb,CC,Inel,ZDC or from track itself). Recall the track length is set as the partial length already stored in the track + the remaining part. Thus one can later recalculate this if there is a need. Add a enumerated class member that tells WHAT vertex is used.

·         The trkVtxZ is the projection on the (yz) plane i.e. along the beamline i.e. independent of vertex used.

·         The trkVtxX is the distance (projection) of the track on the (yx) plane defined by the selected vertex. This is (I think) similar to what was done already for the au-au analysis, and does have the advantage that the difference is approximately independent of spectrometer angle while the difference trkVtxZ-globalVtx has a wider distribution that is much dependent on scattering angle, but of course has precisely the same information content.

·         The scattering angle's should be calculated from the trackProjected vertex. I think you can easily convince yourself that the angles (theta,phi) are not compromised by this. The best case I thibk to redo this consistently in the Refit module using a specific vertex, and also hits in the chambers, not only positions.

 

 I think this fulfill both the opinions of  DO, and of Kris and myself, while keeping changes to a minimum. Also it means the same class members has the same meaning at At minimum the following code and data classes has to be reviewed to make sure we can carry the information to the very end analysis, with bdsts.

 

i)                     BrFfsTrackingModule. Implement the considerations above

ii)                   BrFsGlobalTrackfitModule. Make sure the same definitions and filling is done here as in Ffs

iii)                  BrFsTracking module , ensure data are moved properly.

iv)                 Update BdstClass to keep the vertex information just like this.

 

 

 

 

 

 

 

(*) in fact the tracklength in the Ffs track at least is calculated using straight line segments between all entrance and exit point, discarding the more precise information from the matched tracks that take into account the curvature.

 

vertex methods

enum vtxmethods { kBbVertex=1, kCcVertex, kInlVertex,kTrackVertex]

 

 

 

Some missing information in the Bdst, 

particular relating to D1 and swimming back.

 

Float_t fD1FidX;  // fiducial cuts (relative to nearest surface..)

Float_t fD1FidY;

BrLine3D fD1Tr; // the trackline at entrance to D1 in local coordinates

Int_t     fTrlengthMethod; // see note on vertex and track length 

----------------------------------------------------------------
Flemming Videbaek
Physics Department
Brookhaven National Laboratory

e-mail: videbaek@bnl.gov
phone: 631-344-4106



_______________________________________________
Brahms-dev-l mailing list
Brahms-dev-l@lists.bnl.gov
http://lists.bnl.gov/mailman/listinfo/brahms-dev-l