From: Josh Vermaas (
Date: Mon Sep 08 2014 - 14:23:00 CDT

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
but the bad news is that the trajectory file you have now is probably
unrecoverable, since frame 0 probably got overwritten.

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.