- Chimera-users - RBVI Mailing Lists

suggestion
by Esther Garcia-Rodriguez 07 Mar '05

07 Mar '05

Hi, I am working with structure superposition and I have noticed that labelling relevant residues when two structures or more are superimposed is a bit of a nightmare. As the labels go to C-alpha in all cases it is very difficult to see anything. I would suggest to allow the user to change the default and be able to establish particular positions for labels, as well as the distance from the relevant atom. For example, label all selected residues in one chain at 0.1 angstroms from the CG atom and all of the second chain at 0.2 (in X or Y). Or maybe just been able to change the minimum distance between labels in all directions. Thanks, Esther Esther Garcia Rodriguez Henry Wellcome Building for Biocatalysis University of Exeter Stocker Road Exeter EX4 4QD United Kingdom

2 1

HELIX/SHEET/CONECT records for non-existent bonds/atoms are being inserted into file.pdb when pdbrun nouser cat > file.pdb is run
by Sabuj Pattanayek 07 Mar '05

07 Mar '05

Hi, If I load a pdb, display only selected atoms/bonds, then do pdbrun nouser cat > file.pdb, the outputted pdb file also has HELIX/SHEET/CONECT records for non-existent bonds/atoms (as if the pdb file in its entirety was written out). Is this a bug or a feature? Is there some way to completely turn off output of HELIX/SHEET/CONECT records? Thanks, Sabuj Pattanayek

2 1

"add-vertex" button volume viewer
by Andrew Jewett 02 Mar '05

02 Mar '05

Please forgive and ignore my earlier post. I should have read the manual first. These features are already implemented. I'm sorry. However there are some user-interface issues... In particular, the method for adding and deleting points to the transfer function that determines voxel opacity and color could be more intuitive. (CTRL-click) This can have a big impact. I suggest putting small add-vertex, cut-vertex buttons near the histogram graph (see attatchment #1). (I stole these icons from xv) The results of using multiple vertices to control colors and or brightness-levels are strikingly better than using just two points. It would be good to make it obvious from the user interface that this option is available. Also, each time the user adds another vertex, a new color should be chosen, not the default white, in order to clue the user that the color can be changed. Similarly, it would be good to explicitly have an "add surface" "delete surface" buttons in solid or mesh mode. (No icon necessary, just write the names out in the buttons themselves itself). So go ahead and leave CTRL-Click in, but add buttons to make it explicit, and make the default color change each time a new vertex (or isosurface) is added. I've played with volume-viewer for quite a while, without realizing these options were available. (RTFM, I know...) And these features are _cool_. For example, attatchment#2 is an image of the same phage-T4 shown in the chimera image gallery using multiple colors. I like it a little better than the static grey image that Steve McQuinn made for the image gallery. http://www.cgl.ucsf.edu/chimera/ImageGallery/entries/phageT4/phageT4c.jpg Again, I apologize for my earlier email. Anyway, cheers Andrew okay, back to work...

2 2

colormap -and- opacity functions for voxels
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. I've asked a lot of questions, and I keep getting these long thoughtful and technical replies. Thanks. It's nice to get these replies However don't feel obligated to reply at all, at least when I post a question. The other features I mentioned are more important to me at least. I don't want you to be kept busy replying to emails. The question is: why not have a simultaneous independent opacity-map and color-maps for voxel-rendering? (...and I suppose, why do they have to be linear functions? Is piecewise linear hard to implement?) It seems unnecessary that the voxel values should only determine the opacity of the voxel. It seems reasonable to allow the color to be determined by the volxel value in addition to the opacity (for example, a cold-to-warm-to-hot color scheme). It looks like some kind of colormap user interface has been implemented in chimera. (Nice T4-phage slab image, by the way..) Would this be hard? This way, one could distinguish the DNA inside the T4 phage from the within capsid shell. Currently, 3-D volumetric rendering is cool, but it needs ...something. Since the demand for voxel rendering is probably low, I would understand if you choose to delay to ignore these issues. Andrew ------- That's the end of my question, but I included ------- some pictures at the end, for comparison. ------- You can skip this part. ------- They are not in color, but they do look ...pretty. ------- I wonder what they are doing? http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F5 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F19 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F8B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F16A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F17 Probably the main reason it looks so nice I think is because their data is manifestly much less bumpy than electron microscopy data. Also I'm suspect that increadibly expensive 3-D hardware doesn't hurt either. However there is something else interesting going on in these pictures. It seems that what appear to be fully opaque objects have a range of brightnesses/colors. In chimera, fully opaque objects are solid white (or blue or whatever color is set by the user) and they have no features except their somewhat fuzzy silhouette. The source of these pictures is a paper published at: http://radiographics.rsnajnls.org/cgi/content/full/19/3/745 One thing they talked about in the article was that they use separate brightness and opacity functions as a function of voxel value. They also use more general piecewise-linear functions instead of linear ones ("percentage classification"). The combination of those two features might explain something. Anyway, I wonder what they are doing. No need to reply. I'd rather you work on other stuff right now. Cheers! Andrew

1 0

per-model-clipping needs "all models" option
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. Please forgive me for sending this message twice. In the first version, I forgot to include a subject line, so I'm sending it again. --------------- On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

3 4

by Andrew Jewett 25 Feb '05

25 Feb '05

On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

1 0

Re: pdb parsing problem-- hydrogen as mercury
by Josh Tasman 18 Feb '05

18 Feb '05

Eric and Greg, Thanks for your comments and help. Eric, thanks especially for the concise script. Dealing with the variety of non-standard-format PDB files is truly maddening, and I appreciate the help. Josh

1 0

pdb parsing problem-- hydrogen as mercury
by Josh Tasman 18 Feb '05

18 Feb '05

I'm getting errors on reading PDB files containin hydrogens added by TRIPOS SYBYL. For example, the atoms 1677-1679 are parsed as Mercury (HG): ATOM 1674 HD11 ILE A 107 4.939 -2.338 17.094 1.00 0.00 ATOM 1675 HD12 ILE A 107 6.613 -2.979 16.971 1.00 0.00 ATOM 1676 HD13 ILE A 107 5.703 -3.133 18.512 1.00 0.00 ATOM 1677 HG21 ILE A 107 4.770 -2.095 20.141 1.00 0.00 ATOM 1678 HG22 ILE A 107 6.235 -1.314 20.827 1.00 0.00 ATOM 1679 HG23 ILE A 107 4.630 -0.527 21.006 1.00 0.00 ATOM 1680 H ILE A 107 5.291 0.799 16.773 1.00 0.00 ATOM 1681 N TYR A 108 3.267 1.810 19.498 1.00 21.63 Accoring to the table at http://www.bmrb.wisc.edu/ref_info/atom_nom.tbl There are descrepencies between PDB-like file formats, and we see that the official PDB format would specify "1HG2" instead of "HG21". Does anyone know of a quick way to deal with this? I can write a perl search/replace script if need be. Thanks, Josh

3 2

Re: [Chimera-users] Percent done
by Greg Couch 09 Feb '05

09 Feb '05

On February 7, 2005, David Belnap wrote: > It would be useful to have a percent done displayed when the image is being > rendered. I have a very large job that has been running for two days. I > think it is still progressing so I have not stopped it. For slower > machines or large jobs, it would be nice to know how far along jobs are. > > Thanks. I'm enjoying Chimera. I'm going to assume that you're having problems when you save images and you'd like an indication of how far along it is. That will slow down the image saving, but probably not very much. I'll look into it. I am really curious about how large a job you're running. The only way it could take two days is if you don't have enough physical memory and the system is paging memory to and from the disk. Some operating systems are better at handling programs that need more memory than is physically available than others (ie., BSD Unix and Linux), but all do poorly. Any system that doesn't exhaust memory, should be saveable in minutes. So, you should get some more physical memory for your computer if at all possible. We are working on making chimera more memory efficient, but that work won't be done until May or so. Thank you for using chimera, Greg Couch UCSF Computer Graphics Lab gregc(a)cgl.ucsf.edu

1 0

Percent done
by David Belnap 07 Feb '05

07 Feb '05

It would be useful to have a percent done displayed when the image is being rendered. I have a very large job that has been running for two days. I think it is still progressing so I have not stopped it. For slower machines or large jobs, it would be nice to know how far along jobs are. Thanks. I'm enjoying Chimera. David ============================================ David M. Belnap Department of Chemistry and Biochemistry Brigham Young University Provo, Utah 84602 USA Phone: 801-422-9163 FAX: 801-422-0153 David_Belnap(a)byu.edu ============================================

1 0