July 2010 - Chimera-dev - RBVI Mailing Lists

Re: [chimera-dev] [Chimera-users] alignment + missing residues
by Gesa Volkers 20 Jul '10

20 Jul '10

Dear Eric, thanks for your suggestions. Unfortunately removing the SEQRES record did not help. I also downloaded and installed the new chimera-version today. The false numbering in the alignment still occurs. Also when I remove the SEQRES record and try with the new chimera version the false numbering appears. Quite annoying... The pdb-file is not in the protein data bank yet. Any more suggestions? Could I add "dummy atoms" in the structure? Thanks, Gesa Eric Pettersen schrieb: > On Jul 14, 2010, at 6:53 AM, Gesa Volkers wrote: > >> Dear All, >> >> I observed an issue with the alignment function of Chimera. >> I loaded a crystal structure where in between a loop is not modelled >> due to low electron density- so these residues are missing in the >> structure and the numbering also has this gap. When I align this >> structure with others, the missing residues are not recognized and >> chimera just overrides the numbering so after this loop all the >> numbers in the alignment do not fit anymore to the residues they >> should belong to although the structure and numberings are shown in >> the right way in the graphics window. How can I overcome this issue? >> Should I change the pdb-file? In which way? >> >> Thanks for all responses! > > Hi Gesa, > I had a similar problem reported with 1JFF 12 days ago and haven't yet > worked on fixing it. It seems to only happen for a small subset of > structures. 1JFF has a missing loop and also exactly one missing > residue at the N terminus. Is your structure like that? Is it a > standard PDB entry (if so, what's the ID code)? I'll add you to the > recipient list for the ticket we have open in our bug database for > this (#8585) so you will be notified when it gets fixed. It'll > probably be fairly soon. > Until then the only workaround that occurs to me is for you to remove > the SEQRES records from the PDB file before you open it. Then the > Sequence viewer will depict only the residues physically present in > the structure -- no gaps (incorrect or otherwise) will be depicted. > > --Eric > > Eric Pettersen > > UCSF Computer Graphics Lab > > http://www.cgl.ucsf.edu > > > -- Gesa Volkers Institut für Biochemie, Molekulare Strukturbiologie Felix-Hausdorff-Straße 4 17489 Greifswald Germany +49 (3834)-864392

2 3

Re: [chimera-dev] question about rotations/translations in Chimera
by Thomas Goddard 19 Jul '10

19 Jul '10

Hi Julio, Chimera Python and C++ code represent rotations and translations as 3 row by 4 column matrices with the first 3 columns being a rotation matrix and the 4th column being a translation. The rotation is applied first (about 0,0,0) then the translation. Each map and atomic model in Chimera has its own local coordinate system. The placement of the local coordinate frame in the Chimera global coordinate system (z axis points out of screen, x axis horizontal on screen) is given by one of these 3x4 transformation matrices. The origin of the local coordinate system can be at any point relative to the data. It does not need to be at the corner of the map, nor in the center of the map. The position is specified in the header of many of the map file formats (e.g. MRC). With atomic models (PDB files) from crystallography the origin is usually the crystallographic origin (used for crystallographic point symmetry). There is a 3x4 transform describing how the local coordinate frame is positioned in the global coordinate system. Also for maps there is another 3x4 transform that describes how the grid is positioned within the local coordinate system. This latter transform determines where the data sits in the local coordinate frame the actual data -- the shift is determined by the origin values in map headers. The ability to rotate the grid within the local coordinate frame is generally not supported by map file formats. So if you want to save a rotated map you generally have to resample on a rotated grid -- unfortunate. The Chimera command language allows specifying rotations and translations with the "turn" and "move" commands. These do not use a 3x4 matrix since that is not very useful for hand-typed commands. Instead you can specify the center for a rotation, an axis vector and an angle. For example turn 1,1,0 30 center 150,245.5,90 coordinateSystem #0 model #1 rotates model #1 about axis (1,1,0) by 30 degrees about with center (150,245.5,90) where the axis and center are in the local coordinate system of model #0. There's a lot to know about how coordinate systems are handled in Chimera and I'd need a more specific question to advise you further. Here's a little info about transforms in Python http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/faq.html#q5 And here's some about the "turn" and "move" commands http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/turn.html http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/move.html Tom > Dear Prof. Goddard, > > I came recently to Pawel's group in UT Houston, and we were wondering > about how Chimera performs rotations and translations: in which order, > and with respect to which point (center of the map, origin of > coordinates, corner of the map...)? > > Any info that you can provide to help us clarify this will be greatly > appreciated. > > Best regards, > Julio > >

1 0

Alignment + missing residues
by Gesa Volkers 14 Jul '10

14 Jul '10

Dear All, I observed an issue with the alignment function of Chimera. I loaded a crystal structure where in between a loop is not modelled due to low electron density- so these residues are missing in the structure and the numbering also has this gap. When I align this structure with others, the missing residues are not recognized and chimera just overrides the numbering so after this loop all the numbers in the alignment do not fit anymore to the residues they should belong to although the structure and numberings are shown in the right way in the graphics window. How can I overcome this issue? Should I change the pdb-file? In which way? Thanks for all responses! -- Gesa Volkers Institut für Biochemie, Molekulare Strukturbiologie Felix-Hausdorff-Straße 4 17489 Greifswald Germany +49 (3834)-864392

2 1

Adding atom types in the Gaff parameter files of chimera.
by Jean Didier Pie Marechal 13 Jul '10

13 Jul '10

HI guys, I am trying to add another type of atom in the GAFF parameter file that is called during the minimization process and can't find the right place. Could you give me a hand please? best, JD Dr. Jean-Didier Maréchal Lecturer The Computational Biotechnological Chemistry Team Unitat de Química Física Departament de Química Universitat Autònoma de Barcelona Edifici C.n. 08193 Cerdanyola (Barcelona) Tel: +34.935814936 e-mail: JeanDidier.Marechal(a)uab.es www: http://asklipio.qf.uab.es ----- Missatge original ----- De: chimera-dev-request(a)cgl.ucsf.edu Data: Dimecres, Juny 30, 2010 9:00 pm Assumpte: Chimera-dev Digest, Vol 76, Issue 4 > Send Chimera-dev mailing list submissions to > chimera-dev(a)cgl.ucsf.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev > or, via email, send a message with subject or body 'help' to > chimera-dev-request(a)cgl.ucsf.edu > > You can reach the person managing the list at > chimera-dev-owner(a)cgl.ucsf.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Chimera-dev digest..." > > > Today's Topics: > > 1. Re: pil background Image (Greg Couch) > > > -------------------------------------------------------------------- > -- > > Message: 1 > Date: Tue, 29 Jun 2010 14:10:46 -0700 > From: Greg Couch <postmaster(a)cgl.ucsf.edu> > To: Ludovic Autin <autin(a)scripps.edu> > Cc: "chimera-dev(a)cgl.ucsf.edu" <chimera-dev(a)cgl.ucsf.edu> > Subject: Re: [chimera-dev] pil background Image > Message-ID: <4C2A6156.6070100(a)cgl.ucsf.edu> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > Hi Ludovic, > > This is possible, but a little tricky. It requires writing Python > code. So if I were to code a solution (and I may if you don't, but > I > need to fix a few bugs first), I'd make a chimera extension that > would > load an image into an OpenGL texture, then in the 2D drawing pass, > I'd > draw it underneath everything that is currently drawn. The reason > for > using a texture instead of a bitmap is to allow for high resolution > backgrounds for saving images. > > If you are inclined to write this yourself, code for a chimera > extension > that does OpenGL in Python can be found in the CHIMERA/share/Ilabel > package. > > -- Greg > > On 6/23/2010 2:14 PM, Eric Pettersen wrote: > > On Jun 22, 2010, at 1:25 PM, Ludovic Autin wrote: > > > >> Hi, > >> > >> I would like to know if its possible to use a PIL or a raw image > as a > >> background image. > >> And/Or can you help me figure out how to do it (maybe using some > >> volume from image functinoality). > >> Ideally, I would like to be able to update in realtime this > >> background image (either using a thread, or a callback) > > > > Hi Ludovic, > > The developer who could authoritatively answer your question > (Greg > > Couch) is out this week, so I'll take a stab at it: I don't > think so. > > :-) However, if your goal is to, say, make a movie with a > background > > you provide then you could write out image files with a > transparent > > background (described in this message: > > http://www.cgl.ucsf.edu/pipermail/chimera-users/2008- > January/002197.html) > > <http://www.cgl.ucsf.edu/pipermail/chimera-users/2008- > January/002197.html%29> > > and use most any image-processing program to compose the Chimera > > images with the background(s) you prefer. > > Despite my flippant answer in the first sentence, I don't really > know > > if it is possible to directly change the background. When Greg > gets > > back I hope he will comment on that. Perhaps you could say more > about > > what your ultimate goal is? > > > > --Eric > > > > Eric Pettersen > > > > UCSF Computer Graphics Lab > > > > http://www.cgl.ucsf.edu > > > > Hi Ludovic, > > Everything is possible. > >

2 1