Hi, Radek, I think that I would like to keep the G.fNoFfsTracks for the future. On the FFS trigger we are getting many useful particles, including higher pt particles than for the FS tracks (I refer to the acceptances for FFS/FS). In fact, this is what I think Flemming envisaged when splitting the FS/FFS particles at the dst level. A FFS particles should be something less reliable/precise (Ian could tell us more on this...) than a full FS tracks - because of the global refitting module/more information from detectors. Finally, I need the FFS analysis, so let's keep the fNoFfsTracks where it is. Cheers, Catalin. On Thursday 12 January 2006 14:39, Radoslaw Karabowicz wrote: > And. Why do we keep G_fNoFfsTrack then??? > It made quite a lot of confusion... > rk > > On 1/12/06, Flemming Videbaek <videbaek@rcf.rhic.bnl.gov> wrote: > > Well maybe I am confused. Why should there by a second variable > > that tells how many tracks there are > > The _FS parameter specifies precisely that number (namely how > > many BdstFsTrack that was created in the BdstModule..) > > - in general you do not want the same information in two > > different variables, > > this leads to confusion and maintanance problems. > > > > I am not sure I understand the comment on bfs-ffs, (they are, or > > at least > > > > >> information about them). - as far I know only full FS tracks > > >> are store > > > > in the FS branch. > > Are you talking about info in G. ?? > > > > > > Flemming > > > > > > -------------------------------------------- > > Flemming Videbaek > > Physics Department > > Bldg 510-D > > Brookhaven National Laboratory > > Upton, NY11973 > > > > phone: 631-344-4106 > > fax: 631-344-1334 > > e-mail: videbaek @ bnl.gov > > ----- Original Message ----- > > From: "Catalin Ristea" <ristea@nbi.dk > > > To: <brahms-dev-l@lists.bnl.gov> > > Sent: Thursday, January 12, 2006 6:55 AM > > Subject: Re: [Brahms-dev-l] Dst problem > > > > > Hi, Radek, > > > > > > The work around I've used so far is to iterate over the FS_ > > > in the dst... I've talked with Truls, and he does not agree > > > this solution - he thinks we should not rely on something which > > > is not stored... I think he proposed the solution to replace > > > the fNoBfsTracks with fNoFsTracks, which than will become what > > > we need. > > > About the bfs tracks, I was thinking that we store them even > > > without a FFS part just because they could be later used... The > > > huge percent that you're saying surprise me the same as for > > > you... Let's see what other changes we need to bdst package, > > > and then redo the dst. > > > > > > Kind regards, > > > Catalin. > > > > > > On Thursday 12 January 2006 12:34, Radoslaw Karabowicz wrote: > > >> As some of you have already heard it, I have problems > > >> with the dst3 version of auau run04 200. > > >> The problem has been localized and it is connected > > >> with the lack of G.fNoFsTrack, which makes it impossible > > >> to nicely loop over FS tracks. > > >> It shows up like this: > > >> A. Loop over Ffs tracks: > > >> EVENT 9080 > > >> track 0 out of 1 tracks, momentum 34.1937 richRadius = 8.47939 > > >> EVENT 9081 > > >> track 0 out of 3 tracks, momentum 24.3179 richRadius = 8.89382 > > >> track 1 out of 3 tracks, momentum 2.89575e+32 richRadius = 0 > > >> track 2 out of 3 tracks, momentum 1.33417e+31 richRadius = 0 > > >> EVENT 9082 > > >> track 0 out of 2 tracks, momentum 22.971 richRadius = 9.34088 > > >> track 1 out of 2 tracks, momentum 2.89575e+32 richRadius = 0 > > >> EVENT 9083 > > >> EVENT 9084 > > >> EVENT 9085 > > >> track 0 out of 3 tracks, momentum 22.971 richRadius = 9.34088 > > >> track 1 out of 3 tracks, momentum 2.89575e+32 richRadius = 0 > > >> track 2 out of 3 tracks, momentum 1.33417e+31 richRadius = 0 > > >> EVENT 9086 > > >> EVENT 9087 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> EVENT 9088 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> EVENT 9089 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> > > >> B. Loop over Bfs tracks > > >> EVENT 9080 > > >> track 0 out of 1 tracks, momentum 34.1937 richRadius = 8.47939 > > >> EVENT 9081 > > >> track 0 out of 1 tracks, momentum 24.3179 richRadius = 8.89382 > > >> EVENT 9082 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> EVENT 9083 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> EVENT 9084 > > >> track 0 out of 1 tracks, momentum 22.971 richRadius = 9.34088 > > >> EVENT 9085 > > >> EVENT 9086 > > >> EVENT 9087 > > >> EVENT 9088 > > >> EVENT 9089 > > >> > > >> So, it can be only solved by putting: > > >> if ( (TMath::Abs(bdst->FS_fP[t]-oldMomentum)< 0.001) && > > >> > > >> (TMath::Abs(bdst->FS_fRich_fRadius[t]-oldRichRadius)<0.001) ) > > >> continue; > > >> oldMomentum = bdst->FS_fP[t]; > > >> oldRichRadius = bdst->FS_fRich_fRadius[t]; > > >> in the track loop -- but it's not elegant;) > > >> > > >> Is it a bug in DST? Or is there some nice way to get the > > >> number of fs tracks? > > >> > > >> And another problem that seems strange to us. Why are in the > > >> loop over Bfs tracks so many Bfs tracks that doesn't have FFS? > > >> Pawel thinks that: - number of such tracks should be something > > >> like 10% at the beginning (and it seems that is > > >> as high as 50%), > > >> - they shouldn't be put into Dst's anyway (they are, or at > > >> least information about them). > > >> > > >> Greetings, radek > > > > > > -- > > > Catalin Ristea--------------------------------- > > > High Energy and Heavy Ions Group > > > Niels Bohr Institute > > > Blegdamsvej 17, 2100 Copenhagen, Denmark > > > Tel (+45) 35 32 54 04 / Fax (+45) 35 32 50 16 > > > > > > E-mail: catalin.ristea@nbi.dk > > > http : www.nbi.dk/~ristea <http://www.nbi.dk/%7Eristea> > > > ----------------------------------------------- > > > _______________________________________________ > > > 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 -- Catalin Ristea--------------------------------- High Energy and Heavy Ions Group Niels Bohr Institute Blegdamsvej 17, 2100 Copenhagen, Denmark Tel (+45) 35 32 54 04 / Fax (+45) 35 32 50 16 E-mail: catalin.ristea@nbi.dk http : www.nbi.dk/~ristea ----------------------------------------------- _______________________________________________ Brahms-dev-l mailing list Brahms-dev-l@lists.bnl.gov http://lists.bnl.gov/mailman/listinfo/brahms-dev-lReceived on Thu Jan 12 11:00:54 2006
This archive was generated by hypermail 2.1.8 : Thu Jan 12 2006 - 11:01:02 EST