From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Sep 08 2014 - 16:13:11 CDT

Actually, majority of the DCD file could probably be recovered, but Josh is
correct that the head and tail of the file are almost certainly corrupt,
and that may render the usability of the uncorrupt "middle" to be moot.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

On Mon, Sep 08, 2014 at 02:23:00PM -0500, Josh Vermaas wrote:
> Yeah. :( You used a 32-bit build of NAMD, and I'm betting what happened
> is that somewhere internally, a unsigned integer rolled over (4294967295
> + 1 = 0 in unsigned integer math, which is why 32-bits can only address
> 4GB of space), and that there was a file write that went over this
> boundary, and you started overwriting part of your file as the
> simulation continued. The good news is that you can solve this problem
> for yourself so that it never happens again, since there are now 64-bit
> NAMD precompiled NAMD builds available for Windows
> (http://www.ks.uiuc.edu/Development/Download/download.cgi?PackageName=NAMD),
> but the bad news is that the trajectory file you have now is probably
> unrecoverable, since frame 0 probably got overwritten.
> -Josh
>
> On 09/08/2014 02:05 PM, Viswanath Pasumarthi wrote:
> >
> >> Hi Viswanath,
> >>
> >> Just curious, but what operating system/NAMD build are you using? There
> >> are some filesystems/NAMD builds that have hard upper limits on filesize
> >> (FAT16 or 32-bit NAMD builds being possibilities that come to mind), and
> >> weird things start happening when you exceed those limits. I don't know
> >> very much about the internals of the dcd format, but can you at least
> >> load the first frame? Or has the header been corrupted in some way that
> >> VMD and other tools can't recover from? Basically we have no way of
> > I used 64-bit Windows 7 operating system, NAMD_2.9_Win32-multicore, NTFS
> > file system to store DCD file. Also, from what I see from the readdcd run,
> > the DCD header is corrupted as the NAMD tried to overwrite the DCD file
> > once the file size reached the apparent limit of 4 GB (reason is still
> > mystifying to me). The important information relating to endoffile, N (no.
> > of atoms), timestep, DELTA etc. have been overwritten. I suspect it would
> > be not possible to read the file anymore.
> >
> >> knowing, and can't be very helpful with the information provided.
> >>
> >> -Josh Vermaas
> >>
> >> On 09/08/2014 09:03 AM, Viswanath Pasumarthi wrote:
> >>> Hi,
> >>>
> >>> I ran an NAMD simulation using 6 cores of an 8-cored, 8GB RAM, Intel-i7
> >>> processor equipped PC. After running for 26 ns of simulation time, the
> >>> size of the trajectory file has stopped increasing beyond 4 GB. The
> >>> simulation is however finished by restarting from the last available
> >>> coordinates. Now this 4GB DCD trajectory file is not being able to be
> >>> read
> >>> either using VMD or readdcd matlab file. While the VMD says, 'Unable to
> >>> load molecule', fopen function (to read binary files) used in the
> >>> readdcd
> >>> matlab file returns fileID as -1, i.e. not able to open the input binary
> >>> file.
> >>>
> >>> What is the cause the file size of the DCD stopped at 4 GB, despite
> >>> having
> >>> 8 GB RAM memory, and how can I now read this corrupted DCD trajectory
> >>> file?
> >>>
> >>> Thank you,
> >>> Viswanath.
> >>>
> >>>
> >>>
> >>>
> >>

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/