Re: [Brahms-dev-l] Dst problem

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