Warren L. DeLano wrote:
>> 1) "get_area selection" command will return the effective surface area
>> of the dots that you would see from "show dots, selection".  This is a
>> discrete approximation -- not an exact calculation.
>>  
>> 2) you can use the "dot_solvent" setting to control whether you get
>> solvent surface area or a molecular surface area.  1=solvent,
>> 0=molecular
>>  
>> 3) the accuracy of the measurement depends on the density of dots, which
>> is controlled by the "dot_density" setting (1-4).
>>..
>> This code has not been recently validated (though I did check it a
>> couple years back), so I would suggest that people perform some kind of
>> independent check on their system before trusting the results.

I had chance to compare several packages for the computation of accessible 
surface area. My impression is that PyMOL
does give reasonably accurate results... 
Just for instance: for 1KQX:K40 (one more example of buried lysine in protein 
with almost inaccessible cavity) following
code
PyMOL>import pymol
PyMOL>set dot_solvent, 1
PyMOL>set dot_density, 4
PyMOL> iterate resi 40, print(string.join([str(ID), 
name,resn,resi,str(cmd.get_area("id " + str(ID)))]))

gives

315 N LYS 40 0.0
316 CA LYS 40 0.0
319 CB LYS 40 0.0
320 CG LYS 40 5.17457199097
321 CD LYS 40 0.0
322 CE LYS 40 2.47665882111
323 NZ LYS 40 6.23523902893
317 C LYS 40 0.0
318 O LYS 40 0.0

That is *qualitatively* similar to results, computed by libProteinGeometry (M. 
Gerstein Lab) 

315  N   LYS A  40  0.00
316  CA  LYS A  40  0.00
317  C   LYS A  40  0.00
318  O   LYS A  40  0.00
319  CB  LYS A  40  0.00
320  CG  LYS A  40  2.01
321  CD  LYS A  40  0.00
322  CE  LYS A  40  2.53
323  NZ  LYS A  40  2.20

or by GETAREA (W. Brown group)

315 N    LYS    40     0.00
316 CA   LYS    40     0.00
317 C    LYS    40     0.00
318 O    LYS    40     0.00
319 CB   LYS    40     0.00
320 CG   LYS    40     2.78
321 CD   LYS    40     0.00
322 CE   LYS    40     4.48
323 NZ   LYS    40     3.69

and much more reasonable than M. Sanner MSMS results (with -probe_radius 1.4).

In any case, PyMOL performance in this task was prohibitively low. 
It may be well explained, because, as I understood, get_area computation in 
PyMOL is rather "side-effect" of
rendering-oriented algorithm. 

Perhaps, it would be great to decouple "calculation" functionality in PyMOL 
from "presentation" one. The natural way to
do it - is to provide crosstalk between PyMOL and back-end computational kernel 
(somewhat similar to so appealing
crosstalk with MMTK?)

-igor


Reply via email to