I think there is some misunderstanding here. I never said that the track vertex should be the bb vertex. It's more a question of what plane you define for the projection. It seems to me that the plane x = 0 will give you some blown up uncertainty in Z for low spectrometer angles, and that is not good for the track length. This length is evaluated before the refitting module. So, if you change the vertex used for this calculation afterwards, the track object becomes a BrConfusingTrack. And it becomes even more confusing when the front part of the full FS track (ie FFS track) holds another vertex value. Let me summarize the operation we're dealing with here. In the right order : 1- ffs tracking 2- bfs tracking 3- full fs tracking 4- refitting in 1- you have already decided what vertex to use for the track length (BB or inel) in 2- no issue, in 3- the full fs track picks up the vtx info from the ffs part the length is the sum of ffs track length and bfs track length in 4- you reevaluate the vertex for the full fs track but don't check if the rest is consistent (length + ffs vtx) result : confusion. in my opinion, we get to this issue because we deal here with 2 fs track classes. I think that we should have only one, a container of all possible fs info. if the bfs part is not available all the time, fine. but at least, there would be only one fs track vertex, etc. Djam On Thu, 29 Jul 2004, Kris Hagel wrote: > Hello, > Do I understand that we decide that the vertex output of the Global > Fitter will be the projected track vertex. I hope so! I must confess > that I have never understood the philosophy of taking a track, not > worrying abou where it projects to and replacing it with the BB vertex > however reliable it might be. Of course, I have not yet worked on > analysis where I ever had a reliable BB vertex, so maybe this is just my > inexperience showing. It would seem to me that the "correct" > philosophy would be to project the global track back as best you can and > then compare it to the best vertex you have (BB in Au+Au and INEL in > p+p) and in that way try to make a decision as to whether the track > comes from the interaction or from something else. The output from the > fitting function in my opinion must be the projected track. As Flemming > said in a later message, we might consider another variable which has > the BB vertex or whatever vertex you choose. Once you decide that you > have a good track, this stored vertex could be used to calculate lengths > and what have you. But you should NOT throw away the information that > the track is trying to give you by itself. > > Regards > > Kris > > flemming videbaek wrote: > > >Hi Djamel, > > > >we have had some of this discussions before. > >There are two issues at hand here > >-- with auau we have always DEFINED the trackvertex to be the beam-beam > >vertex, and it has worked well, after > > requiring that the diffwerence between (bbVtx and Projected track is > >small this projection can be either > > on the beamline or bB plane it does not matter apart from a different > >sigma. > >-- since we also deal with dAu, and pp and possible also with lighter ions > >where there may not be a BB vertex, we do need to save the projected VtxZ > >also - it should not be replaced by bbVtx - I the later analysis one need to > >have access to different vtx's from the global when making decisions. The > >issue is thus one of FS track lengths as you point out neeed for TOF > > > >Since you always have access to the BbVtx in any analysis is it not better > >then to let the TrkvtxZ be the proper > >projected z (regardless of the witdhs), calculate the lenght as needed. I > >think so. Otherwise add one more > >variable .. > > > >flemming > > > > > > > >---------------------------------------------------------------- > >Flemming Videbaek > >Physics Department > >Brookhaven National Laboratory > > > >e-mail: videbaek@bnl.gov > >phone: 631-344-4106 > >----- Original Message ----- > >From: "Djamel Ouerdane" <ouerdane@nbi.dk> > >To: "Brahms Devel List" <brahms-dev-l@lists.bnl.gov> > >Sent: Thursday, July 29, 2004 6:17 AM > >Subject: Re: [Brahms-dev-l] track vertex issue > > > > > > > > > >>Ok, here is my fix : > >> > >>in the event method, Kris already picked up the BB vertex for some check. > >>All I did is the following : if it turns out that the track vertex in Z is > >>equal to the bb vertex (as done in BrFfsTrackingModule for AuAu), then > >>I don't reevaluate the track vertex. Therefore, the module still works as > >>before in case the BB vertex was not used before during the FFS tracking. > >> > >>I committed the changes and changed the brat version to 2.22.6 and tagged > >>it BRAT-2-22-6. But something will follow soon because of the magnet swim > >>status and some fiducial cut stuff. Stay tuned. Once all of this is done, > >>then I will rerun the condor scripts for gtr and dst (this is kind of fast > >>and runs properly). But please, when you want to jump to some physics > >>analyses (I know it's more fun), check first the basic stuff (reco level). > >> > >>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-l > >> > >> > >> > > > > > >_______________________________________________ > >Brahms-dev-l mailing list > >Brahms-dev-l@lists.bnl.gov > >http://lists.bnl.gov/mailman/listinfo/brahms-dev-l > > > > > > > -- 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 13:54:10 2004
This archive was generated by hypermail 2.1.8 : Thu Jul 29 2004 - 13:54:19 EDT