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