Chi,
Don't be so hard on yourself. I believe that I might be the one who did
that. I was under impresion that all neutral tracks are done first.
Then they are followed by charged once with the qwl or qwr overwritten
if a charge track is found. Perhaps this needs to done that way, even
if my first stab at it was an awkward one.
Cheers, Vitaliy
Chi Zhang wrote:
>Hi,
>
>After Genya showed me the data, I found that there IS a bug in the way
>ntuple is filled. When NC/LADS are fired, qwl/qwr is set to 0, charge
>info from WC tracks are overwritten. This is certainly incorrect behavior.
>Sorry I screw up this one.
>
>I fixed the code in head version and crunched run 9719 in
>~blast/cvs_v3.0/BlastLib2_dev. The problem is gone.
>
>To estimate the damage: for run 9719, please see the table below:
>charge of track left(p>0.1) righ(p>0.1)
> - 4721 3437
> + 25933 15817
> 0 1619 5144
> 5% 21%
>the last line is the number of wrong charge over the sum of three rows
>above.
>
>on left sector, 5% of charged tracks had qwl overwritten to 0, on the
>right, 21% of them were affected. Also, compare e-right to e-left case,
>one also finds 27% difficiency.
>
>I hope this explains the huge difference in tracking efficiency Tancredi
>sees(e-right 50%, e-left 70% compare to pure TOF cuts).
>
>I hope this also explains the missing ed events with electron going
>right but I need to see also.
>
>The bug is fixed in ~blast/cvs_v3.0/BlastLib2, lrn, lrd and
>libBlast.so are recompiled and copied to bin(lib)/lrn_v3.0c (lrd_v3.0c and
>libBlast.so_v3.0c respectively) and then linked to lrn (lrd, libBlast.so).
>
>the run currently going on is 9801, it will be crunched with new code.
>
>Thanks to Genya who spotted this problem.
>
>Chi
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST