From jagan at ins.iictnet.com Tue Feb 1 00:14:07 2005 From: jagan at ins.iictnet.com (Jagannadh Dr B, Scientist) Date: Tue, 1 Feb 2005 13:44:07 +0530 Subject: [Chimera-users] Ribbon for a non-standard peptide Message-ID: <35BB71C9C887D8119B2D00805F57B6F98FE081@ins.iictnet.com> Hi, I am new to Chimera Can any one suggest how one can draw a ribbon for a peptide which has non-standard residues Jagannadh From meng at cgl.ucsf.edu Tue Feb 1 10:19:02 2005 From: meng at cgl.ucsf.edu (Elaine Meng) Date: Tue, 1 Feb 2005 10:19:02 -0800 Subject: [Chimera-users] Ribbon for a non-standard peptide In-Reply-To: <35BB71C9C887D8119B2D00805F57B6F98FE081@ins.iictnet.com> Message-ID: On Tuesday, February 1, 2005, at 12:14 AM, Jagannadh Dr B, Scientist wrote: > Hi, I am new to Chimera > Can any one suggest how one can draw a ribbon for a peptide which has > non-standard residues > Jagannadh Hi Jagannadh, If these nonstandard residues have the same backbone atoms as regular amino acids (N, CA, C, O), it might work already, although it depends on how these residues were specified in the input file. For example, many PDB files have the nonstandard residue selenomethionine, MSE, but the ribbon is drawn just like for the other residues (one such PDB file is 1kko). However, it sounds like you already tried and did not get a ribbon for these residues. It must be that the backbone is different or even that the backbone atoms have different names than N, CA, C, O. You can use the "Residue Class" section of Ribbon Style Editor (Tools... Graphics... Ribbon Style Editor) to define which atoms determine the path of the ribbon for these nonstandard residues. The instructions for creating a Residue Class can be viewed at: http://www.cgl.ucsf.edu/chimera/1.2065/docs/ContributedSoftware/ ribbonstyle/ribbonstyle.html#class Then, you could select the nonstandard residues and then Apply the class you have created to those residues. I can't really get more specific without knowing more about these nonstandard residues, but you can send me e-mail if you get stuck. I hope this helps, Elaine ---- Elaine C. Meng, Ph.D. meng at cgl.ucsf.edu Computer Graphics Lab and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco http://www.cgl.ucsf.edu/home/meng/index.html From conrad at cgl.ucsf.edu Wed Feb 2 09:47:20 2005 From: conrad at cgl.ucsf.edu (Conrad Huang) Date: Wed, 2 Feb 2005 09:47:20 -0800 Subject: [Chimera-users] re H-Bonds in ViewDock In-Reply-To: <58F49C25B66F4C4DA7FE79B9E79C89B905255E@exvicn1-mel.nexus.csiro.au> References: <58F49C25B66F4C4DA7FE79B9E79C89B905255E@exvicn1-mel.nexus.csiro.au> Message-ID: <8a4764a0c5ae7db255f367589ade5912@cgl.ucsf.edu> On Dec 16, 2004, at 9:54 PM, wrote: > Hi Chimera users, > ??????????? I?ve started to use Chimera recently. When using ViewDock > it struck me that it would be very useful, after loading a .mol2 file > of ligands and computing H-bonds between them and the receptor, to be > able to list the number of H-bonds as a column in the ViewDock > ListBox. Or, is it somehow possible to do this already? > (One way to fix this might be to have a script that will write the > number of H-bonds computed for each molecule in a new .mol2 file, and > then read in this modified .mol2 file ?. Has anybody done something in > this fashion?) Unfortunately, this is not possible with the 1.2065 release. However, I've implemented this functionality, and it will be in the next release. In the mean time, if you'd like to try it out, please e-mail me and I can provide a zip/tar file with the new version of ViewDock, which can replace the 1.2065 version with no impact on the rest of Chimera. Conrad From cmoad at indiana.edu Mon Feb 7 07:47:43 2005 From: cmoad at indiana.edu (Charles Moad) Date: Mon, 07 Feb 2005 10:47:43 -0500 Subject: [Chimera-users] Getting an extension handle Message-ID: <42078D9F.3030800@indiana.edu> How would I get get a handle on a running instance of an extension? Specifically, I want to be able to associate my own structures to sequences in the MultAlignViewer. Thanks, Charlie From meng at cgl.ucsf.edu Mon Feb 7 09:44:51 2005 From: meng at cgl.ucsf.edu (Elaine Meng) Date: Mon, 7 Feb 2005 09:44:51 -0800 (PST) Subject: [Chimera-users] Getting an extension handle Message-ID: <200502071744.j17HipAX1840176@guanine.cgl.ucsf.edu> > How would I get get a handle on a running instance of an extension? > Specifically, I want to be able to associate my own structures to > sequences in the MultAlignViewer. Hi Charlie, If I understand you correctly, this is something you can do this in the user interface (without dealing with code). Your structures should automatically associate with the sequences when opened in Chimera, if the structure's sequence and the sequence in the alignment match well enough. Even if they don't, you can "force" the structure to associate using Multalign Viewer's menu option Structure... Associations This option brings up a dialog in which you can specify which of the structures open in Chimera should be associated with a sequence in the alignment. I hope this helps, Elaine --- Elaine C. Meng, Ph.D. meng at cgl.ucsf.edu Computer Graphics Lab and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco http://www.cgl.ucsf.edu/home/meng/index.html From cmoad at indiana.edu Mon Feb 7 10:16:14 2005 From: cmoad at indiana.edu (Charles Moad) Date: Mon, 07 Feb 2005 13:16:14 -0500 Subject: [Chimera-users] Getting an extension handle In-Reply-To: <200502071744.j17HipAX1840176@guanine.cgl.ucsf.edu> References: <200502071744.j17HipAX1840176@guanine.cgl.ucsf.edu> Message-ID: <4207B06E.30203@indiana.edu> Elaine Meng wrote: >>How would I get get a handle on a running instance of an extension? >>Specifically, I want to be able to associate my own structures to >>sequences in the MultAlignViewer. > > > Hi Charlie, > If I understand you correctly, this is something you > can do this in the user interface (without dealing with code). > Your structures should automatically associate with the > sequences when opened in Chimera, if the structure's sequence > and the sequence in the alignment match well enough. Even > if they don't, you can "force" the structure to associate > using Multalign Viewer's menu option > Structure... Associations > This option brings up a dialog in which you can specify > which of the structures open in Chimera should be > associated with a sequence in the alignment. > I am working on a plugin so I do want to be able to do this programatically. Thanks for the hint on the auto-association. The problem I have now is matching too well. Both sequences are matching the second model loaded. I see I can fix this in the interface, but any clue on how to access this for scripting? Thanks again, Charlie From cmoad at indiana.edu Mon Feb 7 10:50:41 2005 From: cmoad at indiana.edu (Charles Moad) Date: Mon, 07 Feb 2005 13:50:41 -0500 Subject: [Chimera-users] Getting an extension handle In-Reply-To: <4207B06E.30203@indiana.edu> References: <200502071744.j17HipAX1840176@guanine.cgl.ucsf.edu> <4207B06E.30203@indiana.edu> Message-ID: <4207B881.2070602@indiana.edu> Charles Moad wrote: > Elaine Meng wrote: > >>> How would I get get a handle on a running instance of an extension? >>> Specifically, I want to be able to associate my own structures to >>> sequences in the MultAlignViewer. >> >> >> >> Hi Charlie, >> If I understand you correctly, this is something you >> can do this in the user interface (without dealing with code). >> Your structures should automatically associate with the >> sequences when opened in Chimera, if the structure's sequence >> and the sequence in the alignment match well enough. Even >> if they don't, you can "force" the structure to associate >> using Multalign Viewer's menu option >> Structure... Associations >> This option brings up a dialog in which you can specify >> which of the structures open in Chimera should be >> associated with a sequence in the alignment. >> > > I am working on a plugin so I do want to be able to do this > programatically. Thanks for the hint on the auto-association. The > problem I have now is matching too well. Both sequences are matching > the second model loaded. I see I can fix this in the interface, but any > clue on how to access this for scripting? > I think I found my answer by looking at some sources. The following works given my list of models, mdls: for mdl,mseq in map(lambda x,y: (x[0],y), mdls, mav.seqs): mav.disassociate(mdl) mav.associate(mdl.sequences()[0], seq=mseq, force=1) Thanks, From pett at cgl.ucsf.edu Mon Feb 7 10:59:15 2005 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Mon, 7 Feb 2005 10:59:15 -0800 Subject: [Chimera-users] Getting an extension handle In-Reply-To: <4207B881.2070602@indiana.edu> References: <200502071744.j17HipAX1840176@guanine.cgl.ucsf.edu> <4207B06E.30203@indiana.edu> <4207B881.2070602@indiana.edu> Message-ID: <9f6168dc574efe3919587caf29bbfbc7@cgl.ucsf.edu> On Feb 7, 2005, at 10:50 AM, Charles Moad wrote: > I think I found my answer by looking at some sources. The following > works given my list of models, mdls: > > for mdl,mseq in map(lambda x,y: (x[0],y), mdls, mav.seqs): > mav.disassociate(mdl) > mav.associate(mdl.sequences()[0], seq=mseq, force=1) I was preparing a more extensive answer, but you clearly don't need some of the basic stuff I was covering. What I would point out is that if your code is launching the mav instance, you can give "autoAssociate=False" to the constructor so that you don't have to bother with the "disassociate" part of your loop above. Eric Pettersen UCSF Computer Graphics Lab pett at cgl.ucsf.edu http://www.cgl.ucsf.edu From David_Belnap at byu.edu Mon Feb 7 16:01:42 2005 From: David_Belnap at byu.edu (David Belnap) Date: Mon, 7 Feb 2005 17:01:42 -0700 Subject: [Chimera-users] Percent done Message-ID: 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 at byu.edu ============================================ From gregc at cgl.ucsf.edu Wed Feb 9 13:09:37 2005 From: gregc at cgl.ucsf.edu (Greg Couch) Date: Wed, 9 Feb 2005 13:09:37 -0800 (PST) Subject: [Chimera-users] Percent done In-Reply-To: <0eeafe4b0957071fb1fc16f2cdaf709e@cgl.ucsf.edu> References: <0eeafe4b0957071fb1fc16f2cdaf709e@cgl.ucsf.edu> Message-ID: 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 at cgl.ucsf.edu From jtasman at hotmail.com Fri Feb 18 12:17:56 2005 From: jtasman at hotmail.com (Josh Tasman) Date: Fri, 18 Feb 2005 12:17:56 -0800 Subject: [Chimera-users] pdb parsing problem-- hydrogen as mercury Message-ID: <42164D74.8060907@hotmail.com> 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 From gregc at cgl.ucsf.edu Fri Feb 18 14:17:21 2005 From: gregc at cgl.ucsf.edu (Greg Couch) Date: Fri, 18 Feb 2005 14:17:21 -0800 (PST) Subject: [Chimera-users] pdb parsing problem-- hydrogen as mercury In-Reply-To: <42164D74.8060907@hotmail.com> References: <42164D74.8060907@hotmail.com> Message-ID: On Fri, 18 Feb 2005, Josh Tasman wrote: > 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. We'll take the suggestion under advisement. Please file a bug report with TRIPOS. We'd be especially happy if they fixed the names, but it would also help if they put the atomic element symbol in columns 77-78 as allowed by PDB version 2. A perl script is an excellent workaround. Regards, Greg From pett at cgl.ucsf.edu Fri Feb 18 14:32:51 2005 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Fri, 18 Feb 2005 14:32:51 -0800 Subject: [Chimera-users] pdb parsing problem-- hydrogen as mercury In-Reply-To: <42164D74.8060907@hotmail.com> References: <42164D74.8060907@hotmail.com> Message-ID: <2e9c02ef6f2d919a83f69a6cc057535d@cgl.ucsf.edu> Hi Josh, There's a short Python script at the end of this message that produces a fixed PDB file. If there is an 'H' in the problem column and the atom name is four characters long ending in a digit, it will switch the fourth character of the name around to the front. The scripts expects the problem file name as a command-line argument and prints the corrected file to standard output. Hope this helps... Eric Pettersen UCSF Computer Graphics Lab pett at cgl.ucsf.edu http://www.cgl.ucsf.edu --- script --- #!/bin/env python import sys pdbFile = file(sys.argv[1], "rU") for line in pdbFile: if (line.startswith("ATOM ") or line.startswith("HETATM")) and line[12] == "H" and line[15].isdigit(): print line[:12] + line[15] + line[12:15] + line[16:], else: print line, pdbFile.close() From jtasman at hotmail.com Fri Feb 18 16:41:46 2005 From: jtasman at hotmail.com (Josh Tasman) Date: Fri, 18 Feb 2005 16:41:46 -0800 Subject: [Chimera-users] Re: pdb parsing problem-- hydrogen as mercury Message-ID: <42168B4A.9070500@hotmail.com> 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 From aij at physics.ucsb.edu Fri Feb 25 23:12:50 2005 From: aij at physics.ucsb.edu (Andrew Jewett) Date: Fri, 25 Feb 2005 23:12:50 -0800 (PST) Subject: [Chimera-users] In-Reply-To: <200502260540.j1Q5eg3q1985538@guanine.cgl.ucsf.edu> Message-ID: On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users at 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 From aij at physics.ucsb.edu Fri Feb 25 23:14:06 2005 From: aij at physics.ucsb.edu (Andrew Jewett) Date: Fri, 25 Feb 2005 23:14:06 -0800 (PST) Subject: [Chimera-users] per-model-clipping needs "all models" option Message-ID: 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 at 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 From pett at cgl.ucsf.edu Mon Feb 28 10:51:56 2005 From: pett at cgl.ucsf.edu (Eric Pettersen) Date: Mon, 28 Feb 2005 10:51:56 -0800 Subject: [Chimera-users] per-model-clipping needs "all models" option In-Reply-To: References: Message-ID: <48e8bea429a5a8c0d20b5c8daf9cd30e@cgl.ucsf.edu> Hi Andrew, I understand the problem you outline, but am not enamored of the proposed solution. I think it would be quite confusing to have an "All Models" where you could turn clipping on or off and then go to an individual model and turn clipping on or off. How would those interact and would it matter what order you did them in? Anyway, what I am willing to do to try to mitigate the problem you describe is to have Per-Model Clipping's model menu initially select a non-molecule model if available when you bring up the tool. --Eric P.S. Liked the card you gave to Tom. On Feb 25, 2005, at 11:14 PM, Andrew Jewett wrote: > 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 at 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 > > > _______________________________________________ > Chimera-users mailing list > Chimera-users at cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > From aij at physics.ucsb.edu Mon Feb 28 16:56:34 2005 From: aij at physics.ucsb.edu (Andrew Jewett) Date: Mon, 28 Feb 2005 16:56:34 -0800 (PST) Subject: [Chimera-users] clipping (interior surfaces and solids) In-Reply-To: Message-ID: It would be useful to be able set separate surface properties for the interior of opaque closed surfaces that have been made visible by the clipping planes set in Per-Model-Clipping. These are normally backface polygons. This could be complicated to implement in a general way. In my opinion, that's probably not necessary. The only feature that I really pine for is the ability to make the interior surface darker/lighter than the exterior surface. Perhaps a slider could be added to Per-Model-Clipping tool that allows the user to make the backface polygons darker or lighter than the regular polygons. (Perhaps the default should be about 25% darker. That would look pretty and I hope it would be easy to add.) Another feature that would be useful is the ability to make the closed surfaces look solid so that when you cut into them, instead of seeing the interior, a polygon face is added to close the surface and make it look like a solid object. (For example, lighter-colored surfaces in the cartoon: http://www.biochem.mpg.de/hartl/mhartl/index.html I realize these features should be low on the priority list. Maybee a quicky feature to implement when you get board working on the slow, difficult, useful stuff. Cheers! Andrew On Fri, 25 Feb 2005, Andrew Jewett wrote: > 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 at 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