VMD-L Mailing List

From: maria goranovic (mariagoranovic_at_gmail.com)
Date: Thu Jan 07 2010 - 04:36:42 CST

I was not using any atomselect command or script. Was just loading up
trajectories.

So, here is more information. Before loading VMD, the output of the free
command is:

Mem: 4049216 1749744 2299472 0 59552 1008636
-/+ buffers/cache: 681556 3367660
Swap: 4200956 183500 4017456

So, 3.3 GB of memory is free (2nd line, last number)

After I load a trajectory of 143,393 atoms and 1966 frames, which would
occupy ~ 3226 MB according to the numbers quoted above by John, the output
from the free command is:

Mem: 4049216 4020940 28276 0 324 140548
-/+ buffers/cache: 3880068 169148
Swap: 4200956 1157800 3043156

So, the system is almost out of memory, but still performs quite smoothly,
because there is still ~ 150MB memory free. However, if I load up even 150
more frames, the system would probably hang up (I did not have the courage
to try this again, for fear of having to reboot the system).

I also loaded the same trajectory with a state file (.vmd), which contained
atomselect statements also invoking the "within" command. The performance
remained the same irrespective of whether 1.8.6 or 1.8.7 were used.

So, it seems to me that there are two possible solutions:

One, to buy more memory.

Two, try to use bigdcd. In this case, can someone please advise me how to
view entire trajectories in vmd using bigdcd ?

Thank you all for again for helping out

-maria

On Thu, Jan 7, 2010 at 8:58 AM, Wayne Dawson <dawson_at_bi.a.u-tokyo.ac.jp>wrote:

>
>
>> the fact that people often run into a memory problem with atom selections
>> stems
>> from _memory leaks_ (or rather atom selection leaks). the atomselect
>> comand
>> will create a uniquely named new procedure and return its name. since this
>> name
>> cannot be easily known in advance, scripts assign the return value
>> from atomselect
>> to a variable. this will act like a pointer variable. if you assign it
>> a new atomselect
>> procedure name, before deleting the previous one, the name of the
>> previous one
>> will be lost and thus you will "leak" an atomselection and therefore
>> have a memory leak.
>>
>>
> Axel,
>
> I agree with your comments, but these sorts of land-mines are not obvious
> with the TCL script. For example, in the python environment, when the
> equivalent object is out of scope it is automatically freed. So for
> "atomsel()" in python
>
> for i in range(Nframes)
> atom = atomsel.atomsel('resid 25 and NE2', 0, i)
> xa, ya, za = atom.get('x'), atom.get('y'), atom.get('z')
>
>
> everything is freed in a timely fashion with atomsel(). On the other hand,
> TCL requires the following
>
> for {set i 0} { $i < $Nframes} { incr i} {
> set atom(0) [ atomselect $mol_ID "resid 25 and NE2" frame $i ]
> set xa(0) [ $atom(0) get x ]; set ya(0) [ $atom(0) get y ]; set za(0) [
> $atom(0) get z ]
> $atom(0) delete
> }
>
> xa(0) etc are freed when they go out of scope, but, without "$atom(0)
> delete", atomselect is not.
>
> So it is quite easy to unwittingly make the mistake of creating a memory
> leak with the TCL script as a result.
>
>
> Wayne -----------------------------------------------------------
>
> Bioinformation Engineering Laboratory
> Building 6
> Department of Biotechnology
> Division of Agriculture
> Graduate School of Agricultural and Life Sciences
> The University of Tokyo Yayoi 1-1-1, Bunkyo-ku, Tokyo 113-8657
>
> TEL (+81)-3-5841-5449
> cellphone (+81)-090-5312-9325
>
> 

-- 
Maria G.
Technical University of Denmark
Copenhagen