<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: x-small;">
<pre>Thank you Mark and Francesco,</pre>
<pre>I have repaired the trajectory and only lost 2 frames (40 ps total lost of 500 ns).</pre>
<pre>I used to automate a gmxcheck of each .xtc segment generated with mdrun -noappend and </pre>
<pre>rerun segments that were corrupted ... I may go back to that usage in the future.</pre>
<pre>For completeness, I believe that the filesystem that we are using is capable of locking files</pre>
<pre>because once and a while after a cluster crash I end up unable to restart simulations because</pre>
<pre>the .log file is "locked". In those cases, I do revert back to -noappend for continuations as</pre>
<pre>simply deleting the .log file also makes it impossible to continue the run.</pre>
<pre><br></pre>
<pre>Thank you,</pre>
<pre>Chris.</pre>
<pre><br></pre>
<pre>-- original message --</pre>
<pre>Hi Christopher,
you can try to use the program gmx_rescue, by Marc Baaden to recovery your
trajectory.
Below there is the adderess:
<a href="http://baaden.free.fr/soft/compchem.html">http://baaden.free.fr/soft/compchem.html</a>
Francesco
2012/6/9 Mark Abraham <<a href="http://lists.gromacs.org/mailman/listinfo/gmx-users">Mark.Abraham at anu.edu.au</a>>
><i> On 9/06/2012 7:27 AM, Christopher Neale wrote:
</i>><i>
</i>><i> Dear Users:
</i>><i>
</i>><i> I have a 500 ns trajectory of 65 GB that gives a floating point
</i>><i> exception when I run it through gmxcheck or trjcat (generated and analyzed
</i>><i> with gromacs 4.5.5). Has anybody encountered this? I ran mdrun with -append
</i>><i> so this is the xtc resulting from months of simulation of a 1,000,000 atom
</i>><i> system. If I run trjconv -f md.xtc -b 200000, where the floating point
</i>><i> exception occurred around t=180000 ps in gmxcheck, then I can extract the
</i>><i> readable frames and repair around the damaged section. Still, I'd rather
</i>><i> not lose any data and I had thought that the new default -append option to
</i>><i> mdrun checked for these types of problems at runtime.
</i>><i>
</i>><i>
</i>><i> I've no idea what might happen when some file-system transient occurs
</i>><i> mid-simulation, but if mdrun has managed to compute a checksum on an
</i>><i> incomplete file and stored that in the checkpoint, then the append
</i>><i> mechanism can be none the wiser. The check upon restart is that the
</i>><i> checksum matches, not that the checksum is computed on a file whose
</i>><i> properties would satisfy gmxcheck.
</i>><i>
</i>><i> Note also that some file systems that do not support file locking and this
</i>><i> is known to cause issues (Redmine 924), but I don't know if this is related
</i>><i> to your observation.
</i>><i>
</i>><i> Mark</i></pre>
</div>
</body>
</html>