VMD-L Mailing List

From: Wayne Dawson (dawson_at_bi.a.u-tokyo.ac.jp)
Date: Thu Jan 07 2010 - 01:58:26 CST

>
> 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