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 > > > _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Thu Jul 29 12:55:32 2004
This archive was generated by hypermail 2.1.8 : Thu Jul 29 2004 - 12:55:53 EDT