> Hello, > > I noticed yesterday that the BrFsTrack vertex was different from the > BrFfsTrack vertex. That is in fact weird since the front part of any > BrFsTrack is a BrFfsTrack. After making several i/o tests, I realized that > it was no i/o bug but simply the following : in my main module chain, I > had the BrFsGlobalTrackFitterModule. That is not bad in itself except that > it resets the BrFsTrack vertex by projecting the newly refitted track to > the "beam plane" sitting exactly at z = 0. Actually, this is wrong. After rereading the code, I saw that the plane is X = 0. I don't fully understand this choice : at very small angles, this blows up the vertex resolution in Z. How then can you use it for anything ? in particular TOF PID where you need a good estimation of the path length ? > When in AuAu, we use the > beam-beam counter vertex, that is not good. That might be good in other > cases but not in AuAu. So I will simply change the behavior of this > module. I think that in order to make the change smooth, I just have to > make the beam plane sitting at z = z(track vertex). Thus, if you had used > the beam beam vertex before this track refitting stuff, you should get the > expected track vertex. Of course, this will become then a redundant > operation but I don't want to break code that works for pp or dAu. > > Djam > > > -- Djamel Ouerdane ------------------------------------------o | Niels Bohr Institute | Home: | | Blegdamsvej 17, DK-2100 Ø | Jagtvej 141 2D, | | Fax: +45 35 32 50 16 | DK-2200 Copenhagen N | | Tel: +45 35 32 52 69 | +45 35 86 19 74 | | http://www.nbi.dk/~ouerdane | | ouerdane@nbi.dk | o---------------------------------------------------------o _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Thu Jul 29 04:50:40 2004
This archive was generated by hypermail 2.1.8 : Thu Jul 29 2004 - 04:50:56 EDT