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. > >