[gmx-developers] trajectory files corrupted

Erik Lindahl lindahl at cbr.su.se
Sat Jun 23 08:41:22 CEST 2007


The "usual" trajectory problem is due to the OS buffers, so when a  
run crashes the last couple of kB haven't been written. This has been  
adressed in the head branch of CVS; trajectory and energy file frames  
are now explicitly flushed after each frame to make sure the OS  
buffers are written to disk, so frames are always complete.

However, the description below sounds like a different issue. I don't  
think we've ever had any issues with Gromacs silently corrupting  
output, so I think this is due to the operating system.

In case you're using NFS, make sure you use the "hard" mount option.  
"Soft" mounts seem much nicer in that the client doesn't hang if the  
NFS server goes down, but it is a recipe for disaster (slient data  



On Jun 23, 2007, at 5:21 AM, Mark Abraham wrote:

>> Hi,
>>   As the subject, it happened to me several times when the cluster
>> encountering delay writing on running REM MD. The job is finished
>> without any error, but the trajectories are corrupted. Is it possible
>> to enhance data output?
> Probably the problem is with the buffering and subsequent flushing  
> of your
> output, so you'll need to investigate your system and MPI  
> installation.
> Mark
> _______________________________________________
> gmx-developers mailing list
> gmx-developers at gromacs.org
> http://www.gromacs.org/mailman/listinfo/gmx-developers
> Please don't post (un)subscribe requests to the list. Use the
> www interface or send it to gmx-developers-request at gromacs.org.

More information about the gromacs.org_gmx-developers mailing list