VUB-RECOIL Archives

Vub measurement using recoil of fully reconstructed Bs

VUB-RECOIL@LISTSERV.SLAC.STANFORD.EDU

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Daniele del Re <[log in to unmask]>
Date:
23 Aug 2002 10:00:29 -0700 (PDT)Fri, 23 Aug 2002 10:00:29 -0700 (PDT)
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (39 lines)

Hi all,

 in the last days I noticed very strange behaviours of our analysis code
and differences between the output of code versions with no actual
difference.
 I discovered that if I simply add variables declared in the .hh file I
got different numbers.

 I found a memory corruption for the variable tproTrk. It should have
value in the range 0-1 (it is a probability and I verified this at
root file level) but I got nan's, values<0. and so on.

 Its values depend on the number of variables declared in the .hh and on
the position of the declaration of tproTrk itself.

 Since we use this variable to define the GTVL track criterion (tproTrk[i]
>= 0.) and since we are using GTVL, our track selection could be
screwed up.

 I am not able to find a configuration to get this variable correct at the
moment.

 But this bad behaviour implies a more general comment. How can we know
and discover whether the memory is overwritten or not? This problem could
be present in many variables and it should be very subtle to be
found. Moreover this effect can affect in a different way data and MC
since we are handling more variables in the MC.

 Daniele









ATOM RSS1 RSS2