Hi Urs,
yesterday I spent some time scanning the n00 and o00 root files and I
found that:
	- event selection is basically identical
	- mxhad differs if an event has a kaon in one case and not in the
other one
	- mxhad is identical if the number of identified charged kaons is
the same
	- the number of events with a changed kaon is similar
	- data are identical (only MC changed)

It looks like the kaonID in MC was different and I agree with you that it
looks like the random seed was different. I also tried running a few
events over and over again with different seeds and the order of magnitude
of the changes is the one observed between n00 and o00.

I support your interpretation of the changes as MC statistics
fluctuations, probably due to this anaQA.cc incomprehentions. I am glad
that I managed to recover your result to the last digit with VubAnalysis
ursl-032803. We should probably rename it PRL-tag ...
(are your scripts already in VubAnalysis? otherwise I would add them
before making the very final tag)
	ciao
	ric

On Mon, 31 Mar 2003, Urs Langenegger wrote:

>
> Hoi,
>
> I looked a bit into this.
>
> 0. The n00  jobs were run  Jan 28, the  last three crashed  jobs ended
>    very early  on Jan 29 (that  day was bad for  computing).  The next
>    batch  of  jobs n01  (with  modified  recoilNtp.cc)  did not  start
>    running before Jan  29 afternoon. I still think  that I was careful
>    not to mess up the executables.
>
> 1. I   started   with   VubAnalysis  ale-012303   and   RecoilAnalysis
>    ursl-011403 as the closest tags before running the n00 jobs and ran
>    on  csx-bpcock-2002.  I  could not  reproduce the  results  of n00.
>    (results is p.d. the number of events with IERR < 0).
>
> 2. Just to check, I put  back in the K-lepton charge correlation test.
>    No reproduction of  n00. Again, I think that I  was careful back in
>    January, despite the usual  high-pressure zone approaching from the
>    east ....
>
> 3. I looked at CVS. I see that on Thu Jan 23 07:29:03 2003 someone
>    committed a version of anaQA.cc that re-introduced
>
>      gRandom->SetSeed(processID);
>
>    instead of
>
>      gRandom->SetSeed(randomSeed);
>
>    into  the  executable.   This  is  something that  had  sneaked  in
>    previously and had  been fixed before (read the  commit messages of
>    Nov 28 01:28:41 2002, and also Wed Dec 11 01:28:25 2002) ...
>
>    I fixed this  once again in my commit of Thu  Jan 30 00:10:16 2003,
>    but I do not know whether that affected n00. I guess not.
>
> Therefore  I currently  think that  n00  was running  with a  "random"
> random seed (and  the printout in the logfile is  not relevant, as you
> may see  when perusing CVS  web or the  source of the correct  tag). I
> don't know how to find this out without a timestamp of the executable.
> I think I'll add  that as a default dump like the  env dump we have in
> IbuApp.
>
> Archaeology is  a bit difficult  under time-constraints (not  from the
> east, this time), so I may be  wrong. But I don't think so. But if you
> manage to invest your own time and find something else, please post.
>
> I still see no reason why n00 should be better than o00 or p00.
>
>
> Cheers,
> --U.
>
>