On 9/06/2012 7:27 AM, Christopher Neale wrote:
Dear Users:
I have a 500 ns trajectory of 65 GB that gives a floating point
exception when I run it through gmxcheck or trjcat (generated and
analyzed with gromacs 4.5.5). Has anybody encountered this? I ran
mdrun with -append so this is the xtc resulting from months of
simulation of a 1,000,000 atom system. If I run trjconv -f md.xtc -b
200000, where the floating point exception occurred around t=180000 ps
in gmxcheck, then I can extract the readable frames and repair around
the damaged section. Still, I'd rather not lose any data and I had
thought that the new default -append option to mdrun checked for these
types of problems at runtime.
I've no idea what might happen when some file-system transient occurs
mid-simulation, but if mdrun has managed to compute a checksum on an
incomplete file and stored that in the checkpoint, then the append
mechanism can be none the wiser. The check upon restart is that the
checksum matches, not that the checksum is computed on a file whose
properties would satisfy gmxcheck.
Note also that some file systems that do not support file locking and
this is known to cause issues (Redmine 924), but I don't know if this is
related to your observation.
Mark
--
gmx-users mailing list [email protected]
http://lists.gromacs.org/mailman/listinfo/gmx-users
Please search the archive at
http://www.gromacs.org/Support/Mailing_Lists/Search before posting!
Please don't post (un)subscribe requests to the list. Use the
www interface or send it to [email protected].
Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
