[PyMOL] dss & ribbon representation
Hi pymol community. Two questions. - The dss algorithm is great, a very quick way to assign secondary structure. Is there a way of conserving the information when saving the pdb? Sometimes it's nice to edit the assignment. - In contrast to versions 0.9 and earlier, version 0.93 connects the CA with straight lines in ribbon representation. It looks conspicuously like O. Is there a way of smoothing the ribbon? set ribbon_smooth, 1 doesn't do the trick. Thanks a bunch Andreas -- Andreas Förster Dept of Biochem, Univ of Utah, 20N 1900E, #2460 Eccles Bldg. Salt Lake City, UT 84132, phone: 001.801.585.3919 home: 465 3rd Av, SLC, UT 84103, 001.801.364.0529 http://www.biochem.utah.edu/~andreas
Re: [PyMOL] Spheres and backbone coloring
slo...@mail.med.upenn.edu: > does anyone know how to color only the ribbon of a polypeptide, while > not coloring the CA atoms when using spheres? > duplicate your polypeptide, show the ribbon of one instance and atoms of another one -igor
[PyMOL] you know what would be cool?
When making a movie It would be cool if you could set way-points to create a sophisticated "tour" of your molecule. Each way-point would be a different view of your molecule. Then you could specify the number of frames between any two way-points (views). Each frame would be a specified amount of time and by changing the number of frames you would change the timing for that particular section of the movie. Press the play button and voila your tour begins zooming in, rotating, zooming back out, etc. Would this be difficult to implement? Regards, Scott Classen Scott Classen, Ph.D. ACS Postdoctoral Fellow Department of Molecular & Cell Biology University of California, Berkeley 237 Hildebrand Hall #3206 Berkeley, CA 94720-3206 LAB 510.643.9491 FAX 510.643.9290
[PyMOL] Spheres and backbone coloring
Hi, does anyone know how to color only the ribbon of a polypeptide, while not coloring the CA atoms when using spheres? If I say "color grey, name ca", then the CA atoms of my spheres representations are also colored grey. thanks Avram -- Avram M. Slovic Biochemistry and Molecular Biophysics University of Pennsylvania 420 Curie Blvd. 1010 Stellar Chance Bldg. Philadelphia, PA 19104 L:215-898-3496
[PyMOL] RE: surface area calculation
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 NLYS40 0.00 316 CA LYS40 0.00 317 CLYS40 0.00 318 OLYS40 0.00 319 CB LYS40 0.00 320 CG LYS40 2.78 321 CD LYS40 0.00 322 CE LYS40 4.48 323 NZ LYS40 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
RE: [PyMOL] Reference
http://pymol.sourceforge.net/faq.html#CITE -- mailto:war...@delanoscientific.com Warren L. DeLano, Ph.D. Principal Scientist DeLano Scientific LLC Voice (650)-346-1154 Fax (650)-593-4020 -Original Message- From: pymol-users-ad...@lists.sourceforge.net [mailto:pymol-users-ad...@lists.sourceforge.net] On Behalf Of Chris Sent: Tuesday, November 11, 2003 1:29 AM To: pymol-users@lists.sourceforge.net Subject: [PyMOL] Reference Hi Warren Could you tell me how I should reference Pymol in papers etc? I've tried finding it one the web and i've not seen it Ta Chris
[PyMOL] RE: Stereo parameters, again
> I still do not understand your stereo parameters: the > stereo_angle should > define the rotation (around the y-axis) between the pictures > for the left and > right eye, whereas the stereo_shift should define whether the > origin or > midpoint of the picture is within the plane of the screen or > in front of or > behind it. However, changing the settings of these parameters lead to > completely unexpected results: setting the stereo_shift to > "0" and the > stereo_angle to "3.0" results in a mono picture with no > separation at all, > whereas setting the stereo_shift to "3.0" and the > stereo_angle to "0" leads > also to a mono picture shifted to the back. So, could you > please check this > and maybe explain it again to me? After looking back at the code, I realize that these parameters are perhaps misnamed. These are not the rotations of the objective, but rather parameters input into the stereo equations. stereo_shift is the separation between the two cameras observing the image, expressed as a % of the distance from the objective. stereo_angle is a scaling factor applied to the natural angular difference which would occur between two eyes at that distance, both looking at the objective. Generally speaking stereo_shift is the main depth control parameter, and stereo_angle should remain close to 2 in order to generate "correct" stereo geometry. However, adjusting stereo_angle can reduce ghosting and change the apparent Z location of the objective. Detting stereo_shift to zero makes you a Cyclops (you're basically telling PyMOL that your eyes are superimposed). The defaults are: PyMOL>get stereo_shift, get: stereo_shift = 2.0 PyMOL>get stereo_angle, get: stereo_angle = 2.1 which are tuned to minimize CrystalEyes "ghosting" in the foreground. The actual translation(+/-) and rotation(+/-) of the camera at "distance" are: translation = distance * (stereo_shift/100) rotation = (stereo_angle/2) * (arctan(stereo_shift/100)) (default = +/- 1.2 deg) If you want a stronger stereo effect, set stereo_shift to 3, 4, or 5 (resulting in rotations of 1.8, 2.4, and 3.0 degrees, respectively). Cheers, Warren
[PyMOL] stereo inversion?
Dear PyMol users, I've got an annoying effect under RedHat 9.0 with a Nvidia Quadro4 980 XGL graphics card, the most recent Nvidia driver and Stereographics glasses & emitter: occasionally, the hardware stereo is inverted (back appears in front and vice versa) and doesn't come back to normal mode. I've already set the environment variable "__GL_SYNC_TO_VBLANK=On", and in the XF86config I've defined the Device as follows: Section "Device" Identifier "Nvidia1" BoardName"Quadro4 980 XGL" Driver "nvidia" Option "stereo" "3" Option "NvAgp" "1" Option "UBB" "On" Option "PageFlip" "On" Option "WindowFlip" "On" BusID"PCI:1:0:0" EndSection This happens also without setting the UBB, PageFlip and WindowFlip options. Do you have any idea what's going wrong here? I would be very grateful for any hint! Best regards, Dirk. -- "Make everthing as simple as possible, but not simpler." Albert Einstein Dirk Kostrewa Paul Scherrer Institut Life Sciences, OFLC/110 CH-5232 Villigen PSI, Switzerland Phone: +41-56-310-4722 Fax:+41-56-310-5288 E-mail: dirk.kostr...@psi.ch http://sb.web.psi.ch