In addition to these, I noticed once (only once!) that the size
of the raw file copied on spuds was 128kB, although it was 400 MB
on dblast07 (a "move" problem!). And, the lrn crashed during the
start sequence. Copying it manually to the spud worked fine.
-- ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--- Taylan Akdogan Massachusetts Institute of Technology akdogan@mit.edu Department of Physics Phn:+1-617-258-0801 Laboratory for Nuclear Science Fax:+1-617-258-5440 Room 26-402b ---=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=---On Jul 18, 2004, at 10:37, Tancredi Botto wrote:
> >> Good runs: 9046-9048, 9050-9053, 9055-9061; crunching was caught up. >> One >> problem is that during crunching too many runs met the "segmentation >> violation" problem. Don't know why. Can some expert give an answer? > > well the code sometimes seg faults. This runs are not lost but may not > be immediately used. It would be nice if they show up clearly in the > runlist/logbook as "run #### crashed after event 81,500..." > > Another problem is that sometimes lrn does not start on a given spud > ("file not found"). I suspect this is some sort of NFS time out, > however > I've also noticed that in these cases it is enough to do > > cd > lrn #### > > and all is well. > >
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST