Hi
if the analysis begins with flr ntuples, the bug related to dstheader
should not matter. it happend because I mistakenly thought that default
copier generated by the compiler would correctly copy information from one
dstheader object into another. it turned out I did not handle this one
properly.
Otherwise everything in flr root file seems fine and ed elastic channel
(and e'p channel) seem to be fine.
maybe viewing the events in nsed helps for instance to see if VETO still
works as expected. use nsed -t #### to view events stored in DST. But it
is very hard to imagine anything very very wrong given the nice missing
mass and W spectra shown last Friday.
Good Luck.
Chi
PS.
dst recrunched this time has quite many erroneous tracks going down the
beam line with pid equals to NULL. a quick check showed that these are
tracks recon'ed from erroneous BATS information. for a period of time,
BATS interface to DST was an identical copy of TOF interface so in DST
there are hits in say BATS paddle 14. when BATS reconstruction code is
called on these hits, those wrong tracks emerges. for the moment, we would
have to ignore them. This problem could only be fixed with a crunch from
lrn.
On Mon, 27 Sep 2004, vitaliy ziskin wrote:
> I don't think so, Mike. I checked and the proton asymmetry is fine.
> Yields look ok. Resolution is great. Just no neutron asymmetry. Could
> it be protons. I am getting a higher neutron yield with the recrunched
> data, then again there is a higher proton yield by about the same
> factor. I give up.
>
> Vitaliy
>
> Michael Kohl wrote:
>
> >Vitaliy,
> >
> >Chi mentioned to me that in this BlastLib version the dst header
> >information is not copied over. Maybe this is related to your problem?!
> >
> >Look at the yields for each spin state separately if your asymmetries are
> >inconclusive.
> >
> >Regards,
> >
> > Michael
> >
> >
> >
> >
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST