From: Axel Kohlmeyer (
Date: Mon Oct 15 2007 - 15:56:28 CDT

On Mon, 15 Oct 2007, Corenflos, Steven Charles wrote:

SC> First of all I apologize if I don't convey the necessary
SC> information. I'm doing technical support for a chemistry lab which
SC> has brought me to this mailing list.

hi steve,

don't worry about this. there are probably quite a few people
around that understand your situation very well.
SC> I open VMD and go to File->New Molecule. I have two molecules I'm
SC> working with: one is a 177 MB .dx file, and the other is a 3.5 GB
SC> .dx file. The 177 MB file (we can call it A), opens just fine.
SC> Attempting to open the 3.5 GB file (which we'll call B) causes top
SC> to show 100% CPU usage on one of the CPUs, and variable memory usage
SC> usually in the range of 15-17%. This continues for several minutes
SC> until the program spontaneously terminates.

in order to get more specific information about when and where
VMD crashes, you could start VMD in the debugger using the -debug flag.

SC> I'm running this on a dual-processor, dual-core Xeon 3.06 GHz server with 6 GB of RAM, running Gentoo Linux.

are you running a 32-bit or a 64-bit OS and VMD version? with the 32-bit
you may be simply running out of memory...

SC> In case it's relevent I also want to point out that it's only using
SC> 100% of one core; top shows only 25% total CPU usage. Also I'm

VMD is only in parts multi-threaded and definitely not when reading
data files.

SC> running this on one of our servers because the same file caused an
SC> out-of-memory error on the workstation that was originally
SC> processing it, which had only 1 GB of RAM. I realize it
SC> theoretically should be able to allocate any additional memory it
SC> needs from swap, but since one file opens and the other doesn't (and

again, this can be 32-bitness issue. in 32-bit more x86 machines can
handle up to 64 GB in total, but are still limited to 32-bit in the
available address space per process.

SC> since I wasn't 100% certain vmd wasn't allocating memory directly
SC> instead of through system calls) I decided to try it on our server.

SC> Please let me know what additional information I can provide to help figure this problem out.

just let us know, if the above is helpful and see if you can get
the additional info.


SC> Thanks,
SC> -Steve

Axel Kohlmeyer
   Center for Molecular Modeling   --   University of Pennsylvania
Department of Chemistry, 231 S.34th Street, Philadelphia, PA 19104-6323
tel: 1-215-898-1582,  fax: 1-215-573-6233,  office-tel: 1-215-898-5425
If you make something idiot-proof, the universe creates a better idiot.