From: Josh Vermaas (vermaas2_at_illinois.edu)
Date: Mon Feb 29 2016 - 15:35:40 CST

Hi Davit,

This sounds like you are on Windows and you have just passed the memory addressing limit vmd inherits by being a 32bit executable, which is 4gb. Once enough trajectory is loaded so that it passes the threshold, vmd can't address a memory location and crashes. Striding to reduce the loaded size is normally how people get around this, and use bigdcd ideas for analysis. If you go this route, I'd recommend converting the xtc to something else, since xtc frames aren't the same size on disk and so vmd can't read arbitrary frames efficiently, since it must read every intermediate frame.
Josh

On Feb 29, 2016 11:28 AM, Davit Hakobyan <davhak@gmail.com> wrote:
Dear All,

By now I was successfully loading XTC trajectory file containing 1500 frames to VMD. Now as the simulation is still running and additional 500 ns were generated When trying to load the updated trajectory file containing 2000 frames VMD either crashes after loading some 1600 frames (if all the atoms are visible) or just stops randomly after loading 1623 ((the number can be different at different load attempts) frames (this is when only a selection like "resid 1" is active).

Why I am basically sure that XTC file is correct is because when I try to load the same trajectory file with Stride 10, VMD then loads exactly 200 frames.

The XTC is generated on 64 bit Linux system and VMD is running on 64 bit Windows 7 with 12 GB of RAM, so memory is not a problem.

The system size is ~74000 atoms.

Does someone have any idea how to resolve this?

Thanks a lot for any help.