Re: [Brahms-dev-l] Dst problem

Hi, Thank you Flemming for solution to my problem.
I should have made a loop over FS_ not over G_fNoFfsTrack[0].
However I am in turn surprised why do we use looping over
G_fNoFfsTrack[0], both me and in the banapp?
thank you again

cheers,

Radek

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
> > -----------------------------------------------
> > _______________________________________________
> > 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-l