From: Dan Lussier (
Date: Wed Apr 22 2009 - 03:46:23 CDT

Ok I've done some experimenting with the different call sequences
proposed by Olaf and Axel and was able to do exactly what I wanted for
a smaller system (approx 12000 atoms, 4000 water molecules).

However when I try it with the much larger system (approx 1.8 million
atoms, 600 000 waters) as I was trying before the problem appears to
be simply that memory use explodes and I run out of memory as
suggested by Axel. I have 4 GB memory on my system and as pbc join
runs my memory usage goes from < 1 GB to the maximum in 10-15 seconds.

Is there any way to get around this memory issue? Right now when I am
visualizing a system I load a psf file describing the system bonding,
etc... and then load the large dcd file produced by LAMMPS. For the
larger system this dcd file is 203 MB and contains 10 snapshots of the
system. From what I've gathered DCD files are intended to hold many
snapshots of the system trajectory so I'm wondering if there is a way
to still use them while also working around the memory bottleneck wrt
pbc join? Can I break single snapshots out of a DCD file and use pbc
join on them individually?

Olaf - I can still send you my files if you would like but I don't
think they are of particular interest other than the size of the
system. Would you still like me to send them to you for testing?

Thanks again,


On 18-Apr-09, at 4:11 PM, Axel Kohlmeyer wrote:

> On Sat, 2009-04-18 at 11:18 +0200, Olaf Lenz wrote:
>> Hi!
>> Dan Lussier wrote:
>>> In trying this series of commands I don't get very far though as
>>> the pbc
>>> join ... command causes VMD to crash (terminate called after
>>> throwing an
>>> instance of 'std::bad_alloc' what(): St9bad_alloc).
>> This must be a bug somewhere in VMD as it is an error message of C++,
>> and not of Tcl. Probably the system is very big and this is a simple
>> "Out-of-memory" message? This might in fact be caused by the -ref
>> argument that you used, as the "chain" might easily contain all water
>> molecules. So just test not using the ref argument.
> dan,
> i'd like to support olaf's suggestions. pbc join has to be used with
> great care, its memory use explodes with large systems depending on
> the choice of flags. i have run into some problems because of that
> myself. you may want to follow the sequence of commands with:
> pbc wrap -compound res
> to get something that will more closer resemble your initial choice
> of commands, particularly for long trajectories.
> it would be great if you could upload a set of files/script that
> generates the bad_alloc exception to the VMD public biocore BioFS,
> so that we can look into reproducing the bug with the latest
> development code. thanks.
> axel.
>> Otherwise, to be able to debug, it would help if you could send me
>> the
>> DCD and PSF file (please do not send it to the list, but to me
>> personally).
>> Also, try to use "pbc join res -verbose" which will output some more
>> information which might make it easier to find the problematic
>> piece of
>> code.
>>> At this point I'm not sure where the problem lies because I'm not
>>> sure
>>> that my instructions to the pbc join command are ok as I wasn't
>>> sure how
>>> to interpret the instructions for identifying the 'compound' in
>>> the pbc
>>> join command.
>> I think that your instructions should be OK. The compound argument
>> denotes, what compounds join will try to join. For example, when you
>> simulate a protein, it might be interesting to all atoms of the
>> residues, or the whole chains, depending on what you look at. In your
>> case, you can use "fragment", which will join all atoms that are
>> somehow
>> bonded, but using "res" might be faster - if the water molecules
>> are in
>> fact different residues.
>> Olaf
> --
> =
> ======================================================================
> Axel Kohlmeyer http://
> 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.