Frames and Atom Groups¶
This part shows how to use AtomGroup
in place of Frame
.
Trajectory Frames¶
Frame
instances store only coordinate and some frame related data.
For each frame data, you will a different frame instance:
In [1]: from prody import *
In [2]: dcd = Trajectory('mdm2.dcd')
In [3]: dcd
Out[3]: <Trajectory: mdm2 (next 0 of 500 frames; 1449 atoms)>
In [4]: frame0 = dcd.next()
In [5]: frame0
Out[5]: <Frame: 0 from mdm2 (1449 atoms)>
In [6]: frame1 = dcd.next()
In [7]: frame1
Out[7]: <Frame: 1 from mdm2 (1449 atoms)>
These Frame
instances are different objects:
In [8]: frame0 is frame1
Out[8]: False
When you are not referring to any of these frames anymore in your code, Python garbage collector will free or reuse the memory space that was used by those frames.
Linking Atom Groups¶
When trajectory is not linked to an AtomGroup
(using
link()
), Frame
and AtomGroup
objects
share the same coordinate data. Let’s see how this works:
When an AtomGroup
is linked to the trajectory as follows, things
work differently:
In [9]: pdb = parsePDB('mdm2.pdb')
In [10]: pdb
Out[10]: <AtomGroup: mdm2 (1449 atoms)>
In [11]: dcd.link(pdb)
In [12]: dcd.reset()
We get Frame
instances in the same way:
In [13]: frame0 = dcd.next()
In [14]: frame0
Out[14]: <Frame: 0 from mdm2 (1449 atoms)>
In [15]: pdb.getACSLabel()
Out[15]: 'mdm2 frame 0'
Note that the active coordinate set of the AtomGroup
and its label
will change when we get the next frame:
In [16]: frame1 = dcd.next()
In [17]: frame1
Out[17]: <Frame: 1 from mdm2 (1449 atoms)>
In [18]: pdb.getACSLabel()
Out[18]: 'mdm2 frame 1'
Now the key difference is that the Frame
instances are the same
objects in this case:
In [19]: frame0 is frame1
Out[19]: False
As you see, a new frame was not instantiated. The same frame is reused and
it always points to the coordinates stored in the AtomGroup
.
You can also make Selection
instances that will point to the same
coordinate set. This will allow making a more elaborate analysis of frames.
For an example see Trajectory Analysis II.