Re: [COOT] DNA refine parts separately
Ricardo Leal wrote: Hello, I wonder if this feature was changed in the recent versions of Coot? It has indeed. Progress, eh? Is it possible to refine phosphate, sugar and base separately? Yes. It involves a deal of clicking though. I am using Coot and wincoot 0.33 I hope you mean 0.3.3 not 0.0.33 and apparently none of them allows this. That indeed is the case. Not sufficiently modern. Try a recent 0.5-pre release and look out for Fixed Atoms. Paul. Thanks in advance for your replies. Ricardo From: Paul Emsley Date: Tue Nov 21 2006 - 17:58:19 GMT On Tue, Nov 21, 2006 at 06:07:48PM +0100, Kristina Lakomek wrote: I would like to build a ds DNA in Coot. Does anyone know, whether it is possible to modify / refine the base, the ribose and the phosphate part of each nucleotide separately? No, you can't refine the parts separately. I am not convinced that that is a good idea. You can of course do mutations and move around the individual atoms as you can with any other residue type. You can trivially change from C3'-endo to C2'-endo puckering by pulling on the appropriate atom during regularization (or refinement). Paul.
Re: [COOT] Rotate/Translate Multi-chain complex
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: Hello I would like to rotate/translate a multi-subunit complex, each subunit having a different chain name. Is there a way (maybe a script) that allows this to be done in Coot without attempting to change to a single chain name? I presume that the rotation/translation matrix (m in this case) is given by a LSQ match. If so, you can use the following. If not, you can supply the rotation/translation matrix directly to the transform-coords-molecule function. a rotation/translation matrix is a (list (list m11 m12 m13 m12 m12 m23 m31 m32 m33) (list t1 t2 t3)) Paul. ;; Set these for your case: ;; ;; match residues 10 to 20 in B chain of moving molecule to residues ;; 11 to 21 in chain A of reference molecule. The final 2 means CA ;; match 0 means all atom) (define match-params '(11 21 A 10 20 B 2)) (define ref-mol0) (define moving-mol 2) (clear-lsq-matches) (apply add-lsq-match match-params) (let* ((rc (copy-molecule moving-mol)) (m (apply-lsq-matches ref-mol rc))) (delete-molecule rc) (if m (transform-coords-molecule moving-mol m)))
Re: [COOT] Coot installation problems/errors mac 10.4
Mark Collins wrote: Dear Coot Community, I'm having a few issues installing/running Coot 0.5-pre osx ppc. I have a G4 Powerbook and G4 mac mini, both running 10.4. First the powerbook and mini were hanging with the start (coot) image and the startup log says: ...(looks normal). There are 2 data in /sw/share/coot/lib/data/monomers/u/UR.cif Reading coordinate file: /sw/share/coot/standard-residues.pdb PDB file /sw/share/coot/standard-residues.pdb has been read. Spacegroup: P 1 Cell: 40.631 109.18 93.243 90 90 90 ** (coot:439): WARNING **: Error loading pixmap file: /sw/share/coot/pixmaps/smiles.png art_render_invoke: no image source given Having read the earlier posts ABOUT art_render_invoke Just to recap, art_render_invoke is a irritating warning message about image construction. Many programs that load images trigger it. It has since been removed from the library. I decide to move my sw/ to sw.old/ and reinstall fink as well as coot and all its dependencies. It now launches but still gives errors in the startup log... see attached. I am able to load a model, but am unable to upload any CNS maps (I used model_map_twin.inp) an error to do with headers. I guess the format must be wrong? Maybe. For a short while there was a version of clipper that could not read the headers of some CNS maps. That was corrected. However, if that is the problem - and you do somehow have the older libs, you should trim back the header lines in the CNS map to less than 80 characters. As for the mini, I did almost everything the same as the powerbook except, as an extra step prior to renaming and reinstalling everything, I downloaded and installed the stand-alone 0.4.2 (I think) pre-compiled binary from Bill Scott's site. But I still got the same hanging on the startup image with the same warning art_render_invoke. I then moved sw/ to sw.old and repeated as above. What is strange is that after reinstalling everything I still get the 0.4.2 startup image even though apt-get give me Sorry, coot is already the newest version when I try to install now (ie. 0.5-pre) I feel like this is all a bit confusing, if anything needs further clarification please ask. Thanks in advance, Mark Collins Blimey, what a lot of hoops you seem to need to jump through...(it shouldn't be like that, ideally). For a reason unknown to me, the first time one starts Coot, typically on a mac can take many minutes. After that it starts up fine. That used to be the case, anyway. Paul (not yet a MacCoot user).
Re: [COOT] problems running coot on an intel Imac 10.5.2
William Scott wrote: The Apple X11 guy is now working with coot interesting..! to try to fix the bug that causes it to freeze or crash, and there will likely be a new release soon. The problem is beyond my very limited abilities, I am afraid. So start the download and then go to the pub. Yes, I have that sort of internet connection too... I've been using your cootautoopener and have trouble with crosseye stereo. using a ppc mac and a thin 20 inch diagonal screen, when i expand to a larger viewing area, the stereo images are not the same size. i can sometimes use a work around by quitting and re-starting but this often doesn't work. Hmm... I just noticed this yesterday. For me, the image on the right distorts, squeezed or pulled out (depending on how I resize) but after a few frames of rotation (rather than window resizing), it sorts itself out to the correct image. (That is on FC4). The auto-opener is just a wrapper for a shell script that starts coot for you, so that is probably a red herring. Window resizing in the context of Apple's X11 is a bit buggy. More than likely than not that it is not their bug, in this case. In my case, once I go into stereo mode, and then leave, I can no longer make the window any smaller. Oh dear. Even after revision 946? (I think this is related to the bug that Ethan Merritt mentioned) I saw what you describe on linux once, but not OS X. However, I've seen other weird stuff on OS X that probably is due to the same bug. I have not seen it on OS X either (not surprising :) The safest work-around in this case is to start coot without the auto-saved script, which will resize your window. Size the window so that it is the desired size vertically and then 1/2 of the desired size for stereo horizontally, and then switch into the stereo mode. It should then do the right thing. Yes... If you save the state and then re-start in mono, the window will be too large, so this is an irritation, but I can't think of a better way to deal with it. Not so, after the Ethan Merritt bug was fixed, is my thinking. ( Or is it?) Further notes: I still haven't figured out hardware stereo on 10.5. Unfortunately I don't own such a machine, so I can't do a whole lot. Me neither, for the record. (And I have not yet managed to compile Coot on my 10.5 machine, and I think that that is Apple's showstopper). Paul.
Re: [COOT] Coot for DNA modeling
Nian Huang wrote: Dear all, After putting a ideal double-strand DNA around density, I found it is very hard to move both chain together. Using rotate/translate zone only results in single chain movement. Is there a function in coot that can rotate/translate a whole molecule in an easier way? Oh dear, this is becoming a FAQ. There is no good way to rotate a whole molecule (it's on the list, FYI). You can of course do a translation using Move Molecule Here. The work around (if you want rotation too) is to make a copy, move the chain of the copy, then LSQ move the original to the moved copied chain (ref). Not very elegant, but it will work. Hope that helps, Paul.
Re: [COOT] Hardware stereo default plane of centering - change?
Mark Mayer wrote: Hi Cootaners, Anyone know if its possible to redefine the default Z location for the display in hardware stereo mode? The default value seems to be the plane of the stereo window, and although I can move the plane deeper into the window with control/right-mouse-drag, when I use space-bar to advance to the next atom, the focus jumps back to the default value. Its just a personal preference: I prefer to have atoms and maps I'm working on a bit inside the monitor, instead of having them jumping out of the screen. Hi Mark, The position of the rotation centre to the front and back clipping planes is set for mono viewing (and is quite good in that mode, IMHO). I can believe that you'd like to shove it back a bit in hardware stereo - but you can't do that currently. It should be easy to implement, I think. I'll schedule it for 0.6. Paul.
Re: [COOT] bond thickness
William Scott wrote: (set-bond-thickness 0 3) works but the menu-driven option for me doesn't anymore. Bug? Yes, bug. The workaround (that works for me) is to activate the default molecule. That gets it unstuck. Paul.
Re: [COOT] to regenerate a pdb file from ssm matrix
jenny flower wrote: Hello, I have 4 chains in my pdb, I SSM chain B,C,D to chain A. If I refined chain A, can regenerate a pdb with whole 4 chains from refined chain A, by applying SSM matrix? I see Xterm window show SSM matrix when I do SSM, but somewhere a log file contain this matrix information also? Dear Qing/Jenny Flower, When you say I refined chain A, I am presuming that you mean that you have done some model building using Coot. You then want to apply the edits that you have made each of the chains in your model (applying the NCS transformations as necessary): You should read the user manual, section 5.27 Applying NCS Edits: http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_5.html#SEC134 In your case it seems that you want this function: (copy-from-ncs-master-to-others imol master-chain-id) HTH, Paul.
Re: [COOT] to regenerate a pdb file from ssm matrix
Dear Qing Chen, Woops, sorry - the documentation is out of date - I'll fix it shortly. The copy chain makes exact copies of the master chain (with the NCS transformation applied obviously). Which means of course, mutations, deletions, insertions will be applied too. I have added a NCS copy chain function to Extensions as of revision 1327. That should help. Paul. Qing Chen wrote: Hello Paul, Yes, I did some model building using Coot only of chain A. I checked the link, it is saying: Note that you can currently only apply NCS edits to residues that exist in the other chains. If for example, you had introduced/added residues 1 to 5 in the A chain and wanted to copies those over to the other molecules, then that would not work (88) http://www.ysbl.york.ac.uk/%7Eemsley/coot/doc/chapters/user-manual_fot.html#FOOT88. Since I did renumbering, adding ,deleting residues to chain A, so seems it wouldnot work by apply NCS. Now I would like to run refmac5, so I need a complete model, right? I am a rather beginner, is there any better ways to rebuild in my case(4 molecules in one assymetry unit). thanks On Sun, Aug 10, 2008 at 9:36 PM, Paul Emsley [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: jenny flower wrote: Hello, I have 4 chains in my pdb, I SSM chain B,C,D to chain A. If I refined chain A, can regenerate a pdb with whole 4 chains from refined chain A, by applying SSM matrix? I see Xterm window show SSM matrix when I do SSM, but somewhere a log file contain this matrix information also? Dear Qing/Jenny Flower, When you say I refined chain A, I am presuming that you mean that you have done some model building using Coot. You then want to apply the edits that you have made each of the chains in your model (applying the NCS transformations as necessary): You should read the user manual, section 5.27 Applying NCS Edits: http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_5.html#SEC134 http://www.ysbl.york.ac.uk/%7Eemsley/coot/doc/chapters/user-manual_5.html#SEC134 In your case it seems that you want this function: (copy-from-ncs-master-to-others imol master-chain-id) HTH, Paul.
Re: [COOT] phenix pdp files and coot - FIXED
nihmmayerm wrote: Hi, The problem was that coot choked on the TER and BREAK lines in the PDB, once I removed these 0.4.1 reads the phenix PDBs fine. Hmm... where, I suspect, choked on means parse according to the definition. I have not heard before of a BREAK card and AFAICS, it is not part of the 2.3 standard - so I am not surprised that Coot does not parse your file in the way you might expect. Paul.
Re: [COOT] autostereoscopic displays
Evan Kantrowitz wrote: I am now using an autostereoscopic display (no 3D glasses required) from DTI Technologies. I have been using this display with PyMol and the stereo is great. There is essentially no eye strain and no flicker at all. It does not work correctly with COOT since it requires a slight modification to the side by side stereo mode to work correctly. Essentially the left and right images are rendered full size, then compressed horizontally by half before being displayed. Is it possible to add this mode to COOT or provide info on how to do it so I can make a special version. Here is the exact info from the DTI Technologies website: Do you get fat molecules (too wide) when you use side by side stereo in Coot then? Use of DTI screens is unsupported until they send me one to play with :) Paul.
Re: [COOT] autostereoscopic displays
Evan Kantrowitz wrote: Yes, when you use the side by side in COOT with the autostereoscopic display the molecules are too fat by a factor of 2. You can try this: (set-dti-stereo-mode 1) Paul.
[COOT] non-clickable molecules?
Dear Cooters, I have had reports that in certain circumstances, only the top molecule is clickable - which I am sure can be annoying. However, I have not been able to reproduce this here. So, if you are suffering in this way, please tell me which coot binary tar file you used (and anything else that might be pertinent) and I will have another try at resolving this. 0.5 will be released shortly, that's the plan. Thanks, Paul. (and for those at the recent BCA summer school, the baton build crash has now been fixed - sorry about that).
Re: [COOT] Problem with NCS EDIT
Janesh wrote: Hi, I am having problems executing the NCS EDIT command... I have 2- fold NCS and want to apply the edits from CHAIN A as my master molecule to the B chain. I am using the command following command which is not working... copy-residue-range-from-ncs-master-to-others 0 A either nothing happens or I get error std pipe broken I am using Coot 0.4.1 That would be: (copy-residue-range-from-ncs-master-to-others 0 A) This is/will be improved in 0.5 - there is a GUI for it now. Paul.
Re: [COOT] Partial Occupancy, Alternative Conformations
I wonder if Chrisitan has a different definition of quick and easily... To trim[1] atoms that are below a given map level see Section 6.15 of the user manual: http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_6.html#SEC170 [1] delete or set to zero occupancy. Paul. Dirk Kostrewa wrote: Dear Christian, both tasks can be easily done with coot. To add an alternative conformation, use the Add alt conf button in the Calculate - Model/Fit/Refine window, to change the occupancies of a residue, use Edit - Residue Info. Best regards, Dirk. Am 23.09.2008 um 11:21 schrieb Christian Rausch: Dear all, I am wondering if there's a quick way to set the occupancy for atoms with no (or too low) electron density. Furthermore, is there a way to save two different alternative conformations for the side chain of a residue? Thank you, Christian Rausch __ Biologische Chemie TU München Germany *** Dirk Kostrewa Gene Center, A 5.07 Ludwig-Maximilians-University Feodor-Lynen-Str. 25 81377 Munich Germany Phone: +49-89-2180-76845 Fax: +49-89-2180-76999 E-mail:[EMAIL PROTECTED] ***
[COOT] Coot 0.5 released
The Coot Team are pleased to announce the release of Coot-0.5 Ueno. source: http://www.ysbl.york.ac.uk/~emsley/software/coot-0.5.tar.gz binaries: http://www.ysbl.york.ac.uk/~emsley/software/binaries/stable (binaries for other platforms will be appearing in due course). Paul. Release 0.5 Ueno o FEATURE: Coot now has a Preferences dialog. o FEATURE: Coot now is PDB version 3.0 compliant. o FEATURE: Additional Representations added [Tadeusz Skarzynski]. o FEATURE: Fixed Atoms for refinement have been introduced. o FEATURE: Monomer restraints can be edited in a GUI and are exported to the scripting layer. o FEATURE: Coot can now make difference maps. o FEATURE: The state file now remembers the refinement map number [Herb Klei]. o FEATURE: Add dialog position preferences to Extensions. o FEATURE: The state file now remembers the scroll-wheel (contour changing) map [Kevin Madauss]. o FEATURE: Add a variable reduce-molecule-updates-current, that when set by the user causes an update of the probed molecule, not the generation of a new one [Bob Nolte]. o FEATURE: Add Terminal Residue now assigns the correct residue type (if a PIR sequence has been given for side-chain docking) [Bob Nolte]. o FEATURE: Pukka Puckers? validation tool for RNA. Based on Davis et al. (2007) Molprobity: all atom contacts and structure validation for proteins and nucleic acids, Nucleic Acids Research 35, W375-W383. o FEATURE: Active site hilighting. Cheep and cheerful solid modelling of ligand and neighbouring residues [Herb Klei]. o FEATURE: Double-clicking on an atom labels it (CCP4mg compatibility). o FEATURE: Eigen-flip function added. Use to quickly flip around ligands. o FEATURE: it is now possible to add a setting so that atoms with zero occupancy are not moved when refining: set-refinement-move-atoms-with-zero-occupancy [Rajiv Chopra] o FEATURE: Refmac can be run from Coot without the user having to explicitly set the column labels. o FEATURE: NCS Copy Chain is now available as a GUI extension. o FEATURE: The ability to turn on chi angles that move hydrogens is now available from the Chi Angles dialog. o FEATURE: The About dialog contains references. o CHANGE: Key bindings mechanism has changed. Now we are able to display key binding in a GUI widget. o CHANGE: Molprobity Tools (probe and reduce) will only now work with those binaries that are hybrid_36 enabled. o CHANGE: Picking has been changed to somewhat favour those atoms at the front of the slab. o CHANGE: When deleting a residue while displaying validation graphs, the graphs get updated immediately [JED] o CHANGE: In CA display mode, only CAs can now be picked. o CHANGE: Nudge centre axes are now relative to the screen rather than in world coordinates. o CHANGE: NCS skipping changed. Hopefully faster now [Steven Sheriff]. Also works in the case of hetero dimers with NCS [Phil Evans]. o CHANGE: default bond width changed to 5. o CHANGE: Traffic lights verticalized. o CHANGE: Symmetry colour info added to state file [Doug Kuntz]. o CHANGE: the argument order for mutate scripting function have been canonicalised. o CHANGE: set-symmetry-colour-merge now takes only a fraction argument. o CHANGE: Mutate no longer changes the atom order in the pdb file. o CHANGE: Next Residue/Previous residue reworked so that it now jumps over gaps and goes to the right residue when encountering insertion codes. o CHANGE: Don't allow translation drag of intermediate atoms during rotamer selection. o CHANGE: Reference structures now have strand markup in the header, so they can now be used as the reference structures for Build Strand. o CHANGE: Bond parameters changes (bond width and hydrogens state) now work immediately, no need to press the Apply button [FvD]. o CHANGE: Colour by Chain style also now displays zero occupancy markers [PRE]. o CHANGE: Modelling toolbar can now be removed or docked in different positions. o BUG-FIX: chiral volumes are now correctly handled for multiple monomer bespoke ligand dictionaries. o BUG-FIX: Hydrogens names are better handled after an undo operation - no longer do they fly off when refining [Joel Bard] o BUG-FIX: Non-flexible ligands can be added to ligand search when the flexible? option is selected. Previously the ligand search was aborted. o BUG-FIX: Flexible ligand fitting when the torsion period is 0 and for ligands that have bonding defined from a cif file (no atom left behind). o BUG-FIX: side-by-side stereo mode improved [Randy Read]. o BUG-FIX: Now coot does not crash on when displaying NPD atoms in anisotropic representation [Mitch Miller]. o BUG-FIX:
[COOT] What's in 0.6? [was Re: Will be a 64 bits version of coot 0.5 released?]
Leonardo Castro Palmieri wrote: Congratulations for the great software! Thank you - appreciated. Will be a 64 bits version of coot 0.5 released? Yes... in due course. I'll need to acquire a 64 bit machine/OS to build the nightlies on. I intend now to deal with matter arising from 0.5, have a bit of a rest, a bit more traveling and then work on HAPPy for a while. I need to separate the specs for the next release (2008) and 0.7 (2009), see http://coot.googlecode.com/svn/trunk/TODO If you (anyone) has comments about this, I would be interested to hear them. Top commitments: o P backbone mode for RNA/DNA o Edit a SHELXL file before refinement o backrub on rotamer search o Helix fitting overshoots o PISA output display Like to do: o multiple residue ranges for refinement (e.g. residues from a sphere) o redo sequence view o Fix 64-bit coot problem(s) Paul.
Re: [COOT] Coot 0.5 Model/Fit/Refine colours
Another remark on colours in 0.5: redhat8 (non-pythonic) binaries on RHEL4 seem to have lost colours -- the model/fit/refine window, scripting window etc are all grey. Dear Judit, Oh I see. It's a gtk1 vs gtk2 problem: Please replace your xxx/share/coot/cootrc with the one in: http://www.ysbl.york.ac.uk/~emsley/software/fixes/ We will fix this up properly in the pre-releases. Thanks, Paul.
Re: [COOT] Edit chi angles lost indicator?
Nobuo OKAZAKI wrote: Dear Coot 0.5 users I'm using coot 0.5 (redhat8 binaries) on Vine Linux 4.2 (Japanized linux based on redhat 8 or 9). In this version, Edit chi angles lost green indicator for target bond. Yes, sorry. This problem means that 0.5.1 will be needed :-/ Paul.
Re: [COOT] Problem writting Hs
Ricardo Leal wrote: Dear Coot Mailing list, I am using wincoot 0.5 pre (downloaded 1-2 months ago) and I am having problems writing hydrogens (I am refining neutron data) to the output pdb file. Basically coot eats the double prime. Dear Richardo, You need a fresher Coot.
Re: [COOT] SMILES all trans
Giles Robertson wrote: Dear folks, Just wanted to point out that in version 0.5 (and older) the cis trans isomerism gets messed up when reading in the smiles code for a small molecule. For example C/C=C/C looks the same as C/C=C\C. Although it is possible to edit the .cif file manually, I just thought, you know feed back, that kind of thing. Dear Giles, First off, thank you. I'd like to point out that there is no cleverness at all in Coot about SMILES. The merit for that should be to Alexei Vagin and his LIBCHECK. I will inform him of your note. Regards, Paul.
Re: [COOT] Atoms
It turns out that Eugine Krissinel is way ahead of me - in mmdb he provides a flag to fix up the missing elements. This is non-optionally done now in 0.5.1-pre-1 and following versions. Paul Charlie Bond wrote: How straightforward would it be to modify coot to automatically 'run pdbset' on loaded pdb files to overcome this issue? Cheers, Charlie Lynn F. Ten Eyck wrote: On 2 Oct 2008, at 09:11, Kay Diederichs wrote: Phil Evans schrieb: In the new coot, lots of my PDB files have all atoms coloured white. Is this a consequence of the new PDB format conventions Phil Yes I think so - I found that PDB files that behave like that lack the atom type in the last column (which might be req'd by the new PDB format convention - no idea why). The 4-character atom name did not allow well enough for unique identification of the element type, especially with H atoms. Overloading the atom name with element type causes a lot of problems. Separating the atom type to another column allows for both atom type and ionization state -- i.e. correct identification of the scattering factor needed. Example: Atom type Fe -- is it ferrous, ferric, or ferryl? You need to know for both refinement and modeling. Lynn Ten Eyck running through pdbset fixes this easily. best, Kay --Kay Diederichs http://strucbio.biologie.uni-konstanz.de email: [EMAIL PROTECTED] Tel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universitaet Konstanz, Box M647, D-78457 Konstanz .
Re: [COOT] Edit chi angles/refinement does not work for monomers
Les Tari wrote: I realize that I left out a key detail, and had a typo on my last post. I am running Coot 0.5 on OSX (intel). The error message I see when I try to refine a monomer I generate with the CCP4 monomer library sketcher that there are NO restraints found for the ligand (despite the fact that I read in the mon_lib.cif file before reading in the coordinates for the monomer(s) in question). Les, When one successfully reads a dictionary cif file (typically monomer-XXX.cif, if it has come from LIBCHECK via Coot) Coot will tell you that it has read n bonds from the dictionary - if it doesn't do that then I worry. Look for dirty cif? message in the console. Are you sure that the three-letter-codes of the PDB coordintes match that in the cif dictionary? How, more precisely, did you make you dictionary? I presume this is a ligand you designed yourself (and not something in the refmac dictionary?). Paul.
Re: [COOT] environmental distances
S. Shanmuga Sundara Raj wrote: Is there a way to export the environmental distances to a text file? These distances are not saved in the saved state (*.scm). Can you save the session with the environment distances? Not exactly, but you can find the residues that are close (5.5A say) to a given residue (in this case, the residue nearest the centre of the screen): (residues-near-residue (car (active-residue)) (map (lambda (n) (list-ref (active-residue) n)) (list 1 2 3)) 5.5) And we can use that to get to atom position and distance between atoms (see attached). (Note this does not filter the main-chain contacts like environment distances does.) Paul. (define contact-dist-cut-off 3.2) (define (bond-length-from-atoms atom-1 atom-2) (define (bond-length pos-1 pos-2) (define (square x) (* x x)) (sqrt (apply + (map square (map - pos-1 pos-2) (bond-length (list-ref atom-1 2) (list-ref atom-2 2))) (let* ((aa (active-residue)) (imol (car aa)) (active-res-spec (map (lambda (n) (list-ref (active-residue) n)) (list 1 2 3 (let ((residue-specs (residues-near-residue imol active-res-spec contact-dist-cut-off)) (active-res-atoms (apply residue-info (cons imol active-res-spec (for-each (lambda (residue-spec) (let ((atom-list (apply residue-info (cons imol residue-spec (for-each (lambda (neighbour-atom) ;; (format #t active atom: ~s~% neighbour-atom) (for-each (lambda (active-atom) (let ((d (bond-length-from-atoms active-atom neighbour-atom))) (if ( d contact-dist-cut-off) (format #t contact: ~sA: ~s ~s to ~s ~s~% d residue-spec (car neighbour-atom) active-res-spec (car active-atom) active-res-atoms)) atom-list))) residue-specs)))
Re: [COOT] Problem with Coot validation after Phenix twinned refinement
Lieven Buts wrote: Hello all, I have just been experimenting with the refinement options for twinned data in phenix.refine (final 1.3 version), and I ran into a strange problem with the density fit validation function in Coot 0.4 and 0.5. When I auto-open the MTZ file with map coefficients produced by phenix.refine, I get a normal-looking map, but every single residue in the density fit plot is squarely in the red. When I open the 2Fo-Fc CNS format file also produced by phenix.refine, I get a map that looks identical to the first one, and when I validate the same model against the new map, I get the normal density fit pattern, with most residues in the green, and the occasional orange one. So it seems that the density fit calculation goes wrong for MTZ files from twinned refinement. Does anyone know what might be causing this? I can send the data files if required. Randy Read told me about this issue the other day. The density fit graphs work assuming that the map is on the absolute scale - I suspect that your maps have a different scale (test by looking at the absolute level given the same number of sigma). It would be better if Coot used correlation vs a calculated map, but today it does not. You can adjust the scale using Extensions - Refine - Set Density Fit Graph Weight [1] [1] I may move this soon - Settings would seem a better submenu. Paul.
Re: [COOT] Flying hydrogen issue in coot 0.5
In message [EMAIL PROTECTED] Paul Emsley [EMAIL PROTECTED] writes: Hi Mark, The issue here is that the dictionary does not define those atoms for e.g. ARG and GLN. For ARG and GLN, the atoms bound to the CG are HG1 and HG2 - not Hx3. i.e. Coot doesn't know about bonds to those atoms, so it kicks them off with NBC restraints. By what means did you acquire those atoms? There may be a new convention about hydrogen naming that I don't know about... After doing a bit of research (talking to Jeff Headd) I find that indeed the convention has changed. The new format for the hydrogen names are indeed Hx2 and Hx3. grumbleOh dear oh dear, this is going to be a nightmare... I wonder if the PDB have any idea what problems they have caused... I spoke to Ralf recently, he says (IIUC) that they map input pdb names to the new format on reading the coordinates and then *re-map* the atom names to make them match the dictionary. Urgh! And I will have to do the same.../grumble Paul.
Re: [COOT] SSM problem
Yes it should. :-( Paul. In message [EMAIL PROTECTED] junfeng liu [EMAIL PROTECTED] writes: It worked well on old versions. For coot 0.5,it works when you restart coot or overlap small fragment on big one sometimes . That should be a bug. Is it right Paul? Best wishes! liu Engin Ozkan wrote: Hi everyone, I have a peculiar problem. Whenever I copy fragment a domain, the copied fragment fails in SSM. I am not talking about a small fragment, but more like a 250-residue domain. If I save the fragment as a molecule, go back and Open Coordinates that saved fragment, SSM works just fine for that reloaded fragment. It seems like a petty problem (and the workaround I found isn't that hard), but I was wondering if this was a bug or not (for coot 0.5 revision 1444). Thanks, Engin
Re: [COOT] symmetry molecules in H32
James Whittle wrote: Hi- I'm trying for the first time to work with a structure in spacegroup H32. Coot reads the CRYST card, but when I build a helix, or look at a H32 PDB entry, the symmetry mates appear squished. I know there is some discussion about handling this spacegroup: do I need to change the CRYST line to get the structure to display correctly? chuckle what timing :-) OK, so the answer is that Coot does not support such a spacegroup symbol. You need to specify it as R 3 2 :H. Paul
Re: [COOT] symmetry molecules in H32
Eleanor Dodson wrote: Paul Emsley wrote: James Whittle wrote: Hi- I'm trying for the first time to work with a structure in spacegroup H32. Coot reads the CRYST card, but when I build a helix, or look at a H32 PDB entry, the symmetry mates appear squished. I know there is some discussion about handling this spacegroup: do I need to change the CRYST line to get the structure to display correctly? chuckle what timing :-) OK, so the answer is that Coot does not support such a spacegroup symbol. You need to specify it as R 3 2 :H. Paul Paul - you have to fix this - until such time as PDB depositions return such a symbol. At the moment they have H32 Actually, at the moment they have H 3 2. For example, I tried 1B41 and that displays symmetry just fine, as Kevin suggests. James, name an accession code that appears to have squished symmetry (you are using the latest stable version, I take it). Fitting a helix is a different story though, I get a pdb file with a rhombohedral spacegroup but hexagonal cell (which makes a mess of the symmetry related coordinates of course). Both cell and spacegroup for a Fit Helix molecule should be picked up from the map/MTZ file - so I don't know what is going on there. Paul.
Re: [COOT] Problem with Anisotropic B's from Shelx ...
Dear Richard, Richard Kingston wrote: Working with Coot 0.5 revision 1444, I'm seeing strange behavior reading and writing files for Shelx If I simply read in the shelx .res file, then write a .ins file straight back out, the anisotropic B coefficients are changed. An example ... Read in: RESI 3006 HOH O 4 .066672-.410049 .09188011.0 .18111 .15204 = .15826 .01317-.06512-.00049 Written out: RESI 3006 HOH O 4 0.066672000 -0.410049000 0.09188 11.0= 0.21961 0.11403 0.15826 0.01140 -0.071705000 -0.066259604 This is no simple permutation, and doesn't look correct. Am I missing something obvious here? No, I am :-/ I'm working in Trigonal Space Group P3221. That's the issue. I had not checked anisotropic Bs from anything that was not at least orthorhombic. I had not de-orthogonalized the Us. Thanks, I'll fix this soon and get back to you when it's done. Paul.
Re: [COOT] problem in coot installation in ubuntu
FYI, IIUC, Morten Kjeldgaard has become a MOTU and is working on crystallographic libs for Ubuntu, e.g.: https://launchpad.net/ubuntu/+source/clipper https://launchpad.net/ubuntu/+source/mmdb When he gets round to Coot I'm keen to help make his life easier. Regards, Paul. Mark Brooks wrote: Hi, It may be useful to have a 'contrib' section for the Coot binary download web page (or even some unofficial web page), so that we have more options of binaries to test. For example, upon upgrading to Ubuntu Hardy Heron, Coot stopped working, for reasons beyond my understanding, but worked when recompiled. (Which was very easy using the build-it-gtk2-simple script BTW). To have a central repository of tested binaries could be very handy, to avoid having to do this. The Coot developers and yourself (Bill) have done an enormous amount to furnish us with working, tested programs, but perhaps one or two more updated binaries contributed by users would be useful, especially for newer releases of the myriad Linux flavours. I think for the Coot developers to start providing .deb, .rpm and Gentoo packages for every update is too onerous, especially when .tar.gz files work OK. Just my opinion. Which Ubuntu are you on Bill, and which binary are you using? Are these on your debian web site? I guess I may be able to give a Hardy Heron binary if need be. Thanks for your .debs though, I use them all the time. Mark 2008/11/12 William G. Scott [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Since Ubuntu has gotten to be popular (for good reason, IMO), it might be useful to have an official (or at least semi-official) debian package whose installation would guarantee all the dependencies also get installed. I've tried to do it in a half-arsed sort of way, but lately have dropped the ball (sorry). On Wed, Nov 12, 2008 at 1:03 AM, Kevin Cowtan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi! Firstly, do you need to build coot at all? There are binary packages which work just fine on Gutsy. You can install them wherever you want on your system, and they should just work. Secondly, if for some reason you do want to build your own (you want to make changes to the code???), then are you using the build-it-gtk2-simple script? http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/COOT#Installation_from_source_code Building coot without this script requires days or weeks of messing around with dependencies. With this script it is usually pretty easy. Kevin Rimi wrote: Hi all, I am new to coot. Recently I tried to install coot in my ubuntu gutsy. But it can not find mmdb library somehow. Below is the message -- - William G. Scott contact info: http://chemistry.ucsc.edu/~wgscott http://chemistry.ucsc.edu/%7Ewgscott Please reply to: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -- Mark BROOKS Telephone: 0169157968 Fax: 0169853715 Institut de Biochmie et de Biophysique Moleculaire et Cellulaire UMR8619 - Bât 430 - Université de Paris-Sud 91405 Orsay CEDEX Skype: markabrooks
Re: [COOT] DNA mutation
Taufik Al-Sarraj wrote: Hello everyone, I am new to Coot, I am trying to do a DNA mutation but unfortunately i have not been successful. I am using Mutate Residue Range. The error message i get is 'INFO:: mutate 2 to a ALA DISASTER! Not all necessary atoms found in residue 2 CA is missing C is missing N is missing failure to get orientation matrix' I tried the do mutation with a pdb structure from pdb.org http://pdb.org 1DGC, and i tried to do a mutation on a dna created using nucgen in amber. Both attempts gave me the error above. Hello Taufik Al-Sarraj, Sadly mutate-residue-range is for a protein sequence only currently. It does say this here actually http://www.ysbl.york.ac.uk/~emsley/coot/doc/coot-scheme.html#SEC13 but not in the user manual (which I will amend shortly). Now that I look at it, there is no scripting (i.e. ranges) available for nucleic acid mutations. I will make a note to address this lack. So for you right now it's either a clickfest (using Simple Mutate) or some other program - sorry. Regards, Paul.
Re: [COOT] PDB files with insertions numbered 100A, 100B etc.
Aengus Mac Sweeney wrote: Can coot deal with PDB files that have residues numbered 100A, 100B, 100C etc? I can't find a way to make rotamers or auto fit rotamers work for these residues. Hi Aengus, My initial answer to this was of course! - now I tested it and and I think oh dear. High priority to fix. Thanks for the heads up. I'll write back here when those functions work for residues with ins codes. Paul.
Re: [COOT] Get Monomer Function almost freezes system for a while
Sang wrote: I am running Coot 0.5.0-1 on Mac OS X 10.4.11 (Dual 2.7 GHz Power PC G5, 2 GB DDR SDRAM), which was installed with fink. ccp4 is 6.0.2-7, again installed with fink. when I want to get monomer, it freezes quite long time (more than 5 min) to write cif file using refmac. the monomer I tried was DMS, and PO4, which shouldn't be difficult. No, a few seconds. it was a lot quicker when I used Coot 0.3(less than a blink by then). anything I did wrong? or something else? Thanks for the help. I can't think of why it should be slower for you - my thinking is that there may be some sort of refmac issue. What happens (when are the delays) when you do (get-monomer EDO) in the scheme scripting window? Paul.
[COOT] Coot 0.5.2 released
We are pleased to announce the release of Coot-0.5.2. This is mostly a bug-fix release (of 0.5/0.5.1) but a few new features sneaked in too. source: http://www.ysbl.york.ac.uk/~emsley/software/coot-0.5.2.tar.gz binaries: http://www.ysbl.york.ac.uk/~emsley/software/binaries/stable/ Thanks, Paul Bernhard Kevin -- o FEATURE: A Delete Molecule button is now available in the Display Manager [TJS]. o FEATURE: show-rotamer-dialog is now available from the scripting layer (hence `quick rotamer' keybinding) [FvD]. o FEATURE: Manual definition of NCS ghost matrices - GUI added. o FEATURE: overlay-my-ligands function introduced - GUI added. o FEATURE: A simple interface to electrostatic surfaces has been introduced (Extensions - Representations). o FEATURE: rotate-chi feature introduced. For use with a PowerMate. o FEATURE: keyboard-based Go To Residue for quicker navigation. o CHANGE: NCS ghost work using LSQ to get the matrix, not SSM. o CHANGE: Display manager toggle buttons replaced with check buttons. o CHANGE: make-dynamically-transformed-ncs-maps takes an extra argument specifying if new maps should overwrite previous maps of the same name. o CHANGE: Extensions menu re-worked. o CHANGE: Keyboard zooming is now smoothed. o BUG-FIX: the chi angle bond highlighting works again. o BUG-FIX: The Cancel button in Save Restraints now works. o BUG-FIX: Check/Delete waters in Check mode no longer causes a crash when the Close button is clicked. o BUG-FIX: Atom elements are inferred from the atom name. o BUG-FIX: writing of cifs from the Restraints editor has been improved [JED]. o BUG-FIX: chiral restraints specified as BOTH can now be edited. o BUG-FIX: Flip peptide now flips the peptide H atom too [Joel Bard]. o BUG-FIX: Ligands can now have their torsions manipulated in CA+Ligands mode [Ingo Korndoerfer]. o BUG-FIX: NCS residue range edits now apply to more than the first peer. o BUG-FIX: Coot now can read PART cards with a site occupancy factor from a SHELXL .res file [Mirek Gilski]. o BUG-FIX: Fixed crash on using multiple geometry (Distance and Angles) dialogs. o BUG-FIX: The Reset View button has been reworked. o BUG-FIX: Ball Stick additional representations has been reworked and now move as the molecule gets updated. o BUG-FIX: Ramachandran improvement function has been improved. o BUG-FIX: Rotamers and simple refinement now work with residues with insertion codes. o BUG-FIX: The rotamer graph no longer rescales on updating a molecule.
Re: [COOT] [ccp4bb] superpose structures .ssm or lsq which is better
junfeng liu wrote: Dear All, I am overlaying several structures using coot. There are two ways SSM or LSQ can be used in that package. But I got clearly different result form the two methods. In my opinion SSM only works on the secondary structures and LSQ can works on the whole atoms ,main chain or CA. So the question is which one is better to overlay structures, LSQ or SSM ? Dear Liu, Depends on what you are trying to do. If you are trying to overlay proteins that are homologous but have low sequence identity, then finding which atoms/residues match with which can be pretty difficult - hence you would use SSM. If, however, your protein chains are similar (for example, because they are NCS-related perhaps) then LSQ over a particular residue range is probably a better option. Paul.
Re: [COOT] Coot 0.5.2 and Molprobity problem
Hi Ben, Ben Eisenbraun wrote: I seem to be running into the same problem reported by other people with Coot showing a blank clashes window. I'm using the official Coot 0.5.2 python-gtk2 binary on Fedora 10 with probe 2.12 and reduce 3.13. Probe/reduce seem to run correctly; I get a coot-molprobity output directory with files and their exit status is 0, but the dots are never drawn and the Molprobity Probe Clash Gaps window is blank with just a single OK button. I am using 2.12.071128 and that works fine on my Ubuntu machine. On my FC4 machine that causes an immediate crash. However, 2.12.070727 doesn't crash but behaves in the same manner as you describe. look at probe-dots.out. If you have (something like) :1-1:wc:A 6 VAL HG13 :A 92 ILE HA : that fails. If you have :1-1:wc: A 6 VAL HG13 : A 92 ILE HA : that works. Or so I think. If that is not the issue, then I don't know what it is. (The format change is to support hybrid_36 pdb files). An email in a similar thread from Bernhard Lohkamp on 11/18 suggested that if the window was blank, the version of probe was too old, but I don't see a more recent version. We encouraged them to make a new version for Windows. It would be nice if I could have a version that worked on FC4 too. Any clues on what I'm doing wrong would be much appreciated. HTH? See you soon, Paul.
Re: [COOT] no way to calculate an E map
In message 4964b4e6.4000...@ysbl.york.ac.uk e.dod...@ysbl.york.ac.uk writes: At present the only way to calculate an E map via the input option to read an MTZ file is to redefine the COLUMN type of E to that of F Bleugh. Could this be fixed please? Certainly. Paul.
Re: [COOT] overlapping buttons in molprobity check script
Pete Meyer wrote: Using molprobity 3.15 with coot 0.5.2 (gtk1 on ubuntu 7.10 amd64), the dialog box that results from running the molprobity-produced script has overlapping buttons (so problems in one residue are masked by problems in another). Does anyone have any ideas if this is a molprobity (generated script) issue, coot issue, or gtk1/gtk2 issue? It is a gtk1 issue, I think. How about using the gtk2 version? Paul.
Re: [COOT] changing default B factor of new atoms?
Pete Meyer wrote: schemic: (set-default-temperature-factor-for-new-atoms 37) http://www.ysbl.york.ac.uk/~emsley/coot/doc/doxygen/html/c-interface_8h.html#a436 It does appear that this approach doesn't work (at least for adding terminal residues using 0.5.2). You are quite right - my apologies, I should have tested before mailing. I have fixed this (and added a test) in pre-release (rev 1778). Regards, Paul
Re: [COOT] Stepped version of sphere-refine?
Oliver Clarke wrote: That works very well, thanks Judit, and thanks to Paul for the initial script. Is there a way to give refine-zone a list of residues rather than a range? No. There will not be. refine-residues doesn't seem to adopt the restraints I set in refine/regularize control (e.g. ramachandran, secondary structure restraints), but refine-zone does, and I'd quite like to use the ramachandran restraints, as I find they come in very handy at low resolution. I need to check then that refine-residues is handling the extra restraints settings correctly. Or alternatively, if there's a way to set ramachandran restraints for refine-residues via the scripting interface, It should just work - I will try to make it so. Paul.
Re: [COOT] CIF dictionary contains no restraints
Dear Cindy, cindy wrote: I am running Coot 0.1.1 on an SGI. Ah, I am getting forgetful about how things worked in 0.1.1 I'm trying to incorporated methylated lysines into my model, but it is not working. I've done the following File=Get monomer placed the methylated lysine where I want then File=Merge molecules when I try to regularize it, or use real space refine I get a message telling me there are no restraints found. I then import the CIF file generated by coot and it tells me that the CIF dictionary contains no restraints. I have not seen a dirty mmCIF file message OK, this could well be because there are indeed no proper restraints in the cif file. What does your cif file look like? Like that for ALA (complete)? or ATT (minimal)? If minimal, you need to run libcheck/sketcher (or something) to get a complete restraints description. With more modern versions, coot will do that for you, so you'd do (for example): (mutate-by-overlap 0 A 56 MLZ) Section 5.14.3: http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_5.html#SEC118 We have not kept up to date with providing binaries for sgi, the latest one I can see is here: http://www.ysbl.york.ac.uk/~emsley/software/binaries/stable/old/0.3.3/coot-0.3.3-binary-IRIX.tar.gz Paul. p.s. Do consider trying Coot on a Mac or PC - it's somewhat nicer there (IMHO).
Re: [COOT] Coot crash issue
Roger Rowlett wrote: I am experiencing a strange Coot crash issue on some of my Linux workstations. Coot 0.5.2 or 0.6-pre1 crashes with an identical failure mode with the following Coot output (last few lines): [...] load tips.scm load americanisms.scm load group-settings.scm (set-display-lists-for-maps0) load tips-gui.scm /usr/local/bin/coot-0.6-pre1/bin/coot: line 124: 14996 Illegal instruction $coot_real $* coot-exe: /usr/local/bin/coot-0.6-pre1/bin/coot-real coot-version: /usr/local/bin/coot-0.6-pre1/bin/coot-real platform: /bin/uname core: #f No core file found. No debugging I can run Coot 0.5.2 or 0.6-pre1 with no issues on my Q9300 quad-core machine, but on any of my Pentium 4 workstations I get this crash on startup. Coot 0.5.0 runs fine on the Pentium 4's, so it's an issue that developed with 0.5.2 and later. I'm a bit mystified. Hello Roger, I have not seen this before. I don't recall changing anything in this area. As a work-around you can comment out tips.scm in xxx/share/coot/scheme/coot.scm That might do the trick. or add to your ~/.coot file (no-coot-tips) To give details in the crash report please turn on core dumping before running coot. Paul
Re: [COOT] Enhancement Request: Ability to add residues into an empty slot in a chain
Schubert, Carsten [PRDUS] wrote: Would it be possible to enhance the Change Chain ID.. function to allow for insertion of residues into an existing chain if the given resid range is not occupied? if you use the Use Residue Range option you can do this. Could the function be modified in such a way that it checks if the to be renamed sequence actually fits into its designated slot and allows the operation and bails if not? The current exclusion scheme is a bit to broad IMHO. Yes, that would be better than the current situation. However, as there is an alternative path (although not the most obvious, I admit) it is not of the highest priority. Regards, Paul.
Re: [COOT] OS X: coot-0.6-pre-1-revision-1847-1
Engin Ozkan wrote: Hi, it's me again. With the latest version (1848), I haven't been able to use rotate/translate or rigid body functions (they were fine in 1847, I think). No matter what I set it to, the whole chain gets moved by these functions :-( Yes I do too. Will fix.
Re: [COOT] pymol does not cartoon-ize my helices : coot helical restraints
hari jayaram wrote: I have a low-ish resolution (3.5 ) map for a membrane protein. I have been using helical restraints heavily in pymol to do the model building (versions 0.4.2 to 0.5.1 to 0.6 pre release ) . The structure is very homologous to something else and these are really long membrane spanning helices. So a large part of the structure should be helical and thats my justification for using the restraints in coot. I have mostly refined in refmac ( newest 5.3 ) and some in phenix. Both of these pick the refining restraints automagically. My problem is that my helices look perfect in coot , with the torsions and h-bonding looking pretty good .All the traffic lights ( with and without torsional and ramchandran and helical restraints) are green. But pymol simply refuses to cartoonize my helices as helix. I know I can force the pymol cartoon algorithm to treat those regions as helix but am concerned that something is not correct in the way I built my model. Any clues on forcing my helices to conform to what pymols idea of a helix is. The pymol version is also 1.0r2 and does cartoonize everything else as expected. Are the residues in helical secondary structure? (the DSSP algorithm is built in to Coot - perhaps Pymol uses something else to define ss?) You can look at the sequence view (coloured by secondary structure) or view as CA with Secondary Structure to see if Coot (at least) thinks your residues are alpha helices. Paul.
Re: [COOT] O other NCS chain
Jianghai Zhu wrote: Hi, The new version of coot has o key binds to other NCS chain, which is a great shortcut. It works perfectly between my A and C chains. However, it won't work between B and D chains and gives me the following error. (skip-to-next-ncs-chain) ((safe_scheme_command) Error in proc: key: wrong-type-arg args: (string= Wrong type argument in position ~A (expecting ~A): ~S (2 string (B D)) ((B D Hi Jianghai Zhu, Thanks. I get a problem here (NCS heterodimer) too. I'll see if it it fixable. Paul.
Re: [COOT] Dashed Lines
First: good. Second: a technical note: recently I discovered that many (most?) consumer graphics cards do not support GL_LINES [1] for line widths other than 1 pixel - they simulate them using OpenGL quads (quadrilaterals), so it is not completely surprising that somehow the simulation was messed up. In future, I will probably move Coot to using quads directly to bypass the simulation - it may speed things up... Paul. [1] which is what Coot uses to represent most things. Petra Lukacik wrote: Hello All, I just wanted to follow up the Dashed Lines thread I upgraded to Ubuntu 8.10 (Intrepid Ibex) and I reinstalled the fglrx video card driver (xorg-driver-fglrx). I don't know what exactly did the trick but I no longer have the dashed lines problem. Oh and I am currently using coot-Linux-i686-ubuntu-8.04.1-gtk1 from binary. Victory is mine! Petra
Re: [COOT] A problem about peptide link of special residues
Garib Murshudov wrote: Have you declared your modified LYS as L-peptide. It should be be done in the beginning like: data_comp_list loop_ _chem_comp.id _chem_comp.three_letter_code _chem_comp.name _chem_comp.group _chem_comp.number_atoms_all _chem_comp.number_atoms_nh _chem_comp.desc_level LYS LYS 'LYSINE 'L-peptide 22 9 . Garib, Many of the modified lysines in the Refmac dictionary are not marked as L-peptides. Is that something that needs to be fixed in the dictionary? Paul.
Re: [COOT] coot0.6-pre-1 on FC10
Kay Diederichs wrote: David Schwefel schrieb: Dear Coot community, I encountered some problems using Coot on fedora core 10. I installed the binaries, and upon starting, the system crashed just in the moment when the Coot window appeared. I have a ATI radeon X1650 graphics card. When I switch from the standard radeon to the ATI fglrx graphics driver, the system does not crash anymore, but Coot quits with the following error message: [snip] My 2 cents: I'm guessing this is due to compositing or a driver bug. I run Coot on F10 every day and only see suspicious activity when using Nvidia driver. Paul.
Re: [COOT] Key-binding for changing active map/molecule color
Victor Alves wrote: Hi I have looked at the reference manual and can't seem to find a way to fulfill my desire to change colors of the active map or molecule at key-press. All the commands I found use imol which means you have to know the exact number. If you're launching Refmac from within Coot, its useful that Coot changes the map and molecule colors (as it does automatically) but sometimes I don't like the chosen colors and would like to change them, just by pressing a key. So, I would like to add a key binding to set the current (active) map to a certain color and likewise do the same for the active molecule. Something like: (add-key-binding Blue Map b (lambda () (set-map-colour *_active-imol_* 51 128 178)) instead of having to use imol. Hi Victor, First, to make the new maps from Refmac be the same colours as the previous one, add to your ~/.coot file: (set-keep-map-colour-after-refmac 1) Secondly, to answer your question: (add-key-binding Blueify the Latest 2foFc Map b (lambda () (let loop ((l (reverse (map-molecule-list (cond ((null? l) 'no-map) ((= (map-is-difference-map (car l)) 0) (set-map-colour (car l) 0.1 0.5 0.68) (graphics-draw)) (else (loop (cdr l))) i.e. we have to find the value of active-imol and we do that by working backwards through the list of map molecule numbers and finding the first one that is not a difference map. Note the colour scales go from 0 to 1. Paul.
Re: [COOT] Stereo projection with Coot
Schubert, Carsten [PRDUS] wrote: Yep it does. On linux there may be issues, because the drivers may or may not support swap-eyes. The problem is that the images are out of sync with the glasses, or to be more precise, the left image is displayed when the right shutter on the glasses is open. That was the case with the version we are having, not sure if the latest projector is better. This is not a problem if the app allows you to swap eyes, like Pymol. I don't think coot has that capability (yet?) I don't really understand - do you mean simply that the object is back to front? (ie. the front clipping plane is at the back?) If so I would try: (set-hardware-stereo-angle-factor -1.2) (something negative anyway). Paul.
Re: [COOT] python or scheme?
Markus Dehnhardt wrote: Dear cooters, I am new to coot, but I have already discovered how powerful extensions and key bindings can be. My question is quite simple: if I want to generate my own extension or keybinding, which scripting language is better suited? I am not very familiar with either but willing to experiment. There were similar questions already on this mailing list but there are a couple of things that are not clear to me: Some of the documentation is for python some for scheme: the scripting interface is python and the reference manual is scheme. Are all functions awailable for both? Or does one have any advantage over the other? Sigh... Well, you are not the first person to be confused by this. The state of the scripting documentation has been reported as problematic for a while. I don't know what do to about it that does not involved a lot of work. Yes, the User Manual is mostly written with schemey examples. The reference manual I have not looked at for years :-/, the scripting interface page is also automatically generated and provides an interface from a C-programmers point of view - which is very like that for Python. I use often this quite often. The scripting interface for functions written in scheme/python should equivalent access to functions that do the same thing. The syntax of the function calls can be readily converted between scheme and python. There are notes available on how to do this. The functions that we saw today, for example, could have equally well have been written in python. What is other users preference: python or scheme, and why? For those who are not influenced by me, python I'd say. And they chose python because it is more readily picked up for those with an imperative or object-oriented mind-set. Like the dolphins, I'd choose scheme for exactly the same reasons. How often do people, other than developers, create extensions? Hard to say, but my feeling is not often enough. And that is, I suppose, is due to the poor state of the scripting/extension documentation. That and the fact that it takes an investment of time to learn the scripting language, the Coot extensions API and the GUI toolkit. And finally to the scheme scripters: how did you learn scheme? The Little Schemer and Ken Dybvig's The Scheme Programming Language. To answer your question: python or scheme? Yes! We provide the best 2 languages so that you have the choice. How to choose? Read The Little Schemer - if you think it is delightful and stimulating, use sheme. If you think it is hateful, irrelevant and full of irritating silly parentheses, use python. HTH, Paul.
Re: [COOT] how to optimise the geometry in the coot
Jhon Thomas wrote: Hello paul I am completley naive with coot.I am using the coot present with the ccp4-6.0.2, which is an older version of coot. I am facing very difficulty in optimising the geometry of the model in coot.I follow the tutorial for optimisation of the geometry. i go like this. 1) a) real space refinement of particular zone and then regularization the zone. I doubt that that's what it says in the tutorial. real space refinement puts the selected model parts in the density and regularization again optimizes the model part. but, its very hard to maintain the perfect geometry for the model this way.. What is wrong with the geometry? b) Rotate-translate zone followed by real space refinement and then regularaization. You need RTZ? Urgh. but, this i am facing very difficulty in regularization.. I always set the coot real matrix weight around 20. Is this is the correct protocol No. or there is another way to control the refinement and regularization in coot. A rule of thumb: don't use regularization when you have electron density. Go to a good area of the model. Triple refine. Are the traffic lights all green? Good. If not change the weight until they are. Now work on the problematic region... HTH, Paul.
Re: [COOT] Open windows with startup script
Meindert Lamers wrote: Dear all, I was wondering if there is a way to open the following windows using a startup script. -Cell symmetry -Stereo/mono -Refine regularize control -Bond parameters. No, no [1] , no and no. But they would be useful to add - along with the scripting window. Noted. Thanks, Paul. [1] right-mouse click in the horizontal toolbar with python coot to add a Mono/Stereo button (amongst others).
Re: [COOT] N-linked glycosylation
Bottomley, Matthew wrote: Dear Cooters, Is WinCoot able to handle glycosylated Asn residues? If I load my current PDB file that contains an Asn with an N-linked NAG modification the NAG does not appear bonded to the Asn side-chain (whereas in Pymol this connection is drawn). The Asn and NAG have different residue numbers - is that the source of the problem? Any good work-arounds? Dear Matthew, Yes, this is a know issue, there is no work-around (other than the gimp/photoshop :). It is due to be fixed, not that that helps you now. But note that the bond drawing algorithm is different to the restraint generation - so even though the bond is not drawn, can still be used in sphere refinement. Paul.
Re: [COOT] torsion general
Cathy Lawson wrote: I'd be grateful for a short click-by-click description of how to use torsion general. I haven't been able to find documentation for this. Thanks in advance. Hi Cathy, Thanks for pointing out the lack of documentation on this. I'll make a note to add some. You need to click on the torsion-general icon, then click 4 atoms that describe the torsion - the first atom will be the base (non moving) part of the atom tree, on clicking the 4th atom a dialog will pop up with a Reverse button [1]. Move this dialog out of the way and then left mouse click and drag in the main window will rotate the moving/top part of the residue round the clicked atoms 2 and 3. When you are happy, click Accept. Window focus may be an issue - depending on your setting, the window manager may eat one of your clicks as you change focus between the dialog and the main graphics window (this I find annoying and there are instructions in the FAQ on how to turn that off for various systems). Paul. [1] which may not work in 0.6-pre (grumble/sigh/sorry). If it doesn't not work, the Reverse button should invert the moving and base part of the residue.
Re: [COOT] symmetry controller window
Sebastiano Pasqualato wrote: Hi Paul, hi all. I was wondering if there's a way to avoid that a new symmetry controller window opens every time I click on the symmetry by molecule... button of the Show symmetry? dialog, rather than just bringing to the front an already opened one. There isn't. There should be. I'll address that. Thanks, Paul.
Re: [COOT] Coot windows popping up behind main windows on OS X?
Sebastiano Pasqualato wrote: Hi Todd, I've also experienced the same problem with the Save coordinates dialog window. I agree with you this is pretty frustrating. Me too! It is an Apple bug - it came along with 2.3.x, I think. Paul.
Re: [COOT] stereochemical violations in real space refinement?
Yes (indeed), the CG of a LEU is not a chiral centre - and thus is not refined/optimised. If the the CDx atoms are misassigned, then that is what we call a nomenclature error (I think I got the terminology from Refmac). The last chi angle of residues types TYR, PHE, ASP and GLU used to be checked against for IUPAC convention and thus we used to see a nomenclature error for those residues as an outlier in the rotamer graph [1]. VALs and LEUs are not checked in this way for the rotamer graph. However, there is a tool to fix nomenclature errors, and VALs and LEUs are checked there. Have a look in the manual about this: http://www.ysbl.york.ac.uk/~emsley/coot/doc/user-manual.html#SEC146 In the terminal, it will tell you all the nomenclature errors that it found and fixed - i.e. there is no tool in Coot that will just tell you about nomenclature errors without fixing them too. This tool is not available in the GUI - it should be trivial to add an extension. I will make a note to do so. Thanks, Paul. [1] that was before we moved to the Richardson rotamer probability library, that has yet to be rationalised. Dale Tronrud wrote: Yes, real space refinement takes into account stereochemical restraints, that is what all the traffic lights are about. What, exactly, is the PDB complaining about? If it is the chirality of atom CG, then you should realize that this is not a real chiral center. CG becomes chiral when the two CD atoms are given numbers. There are two ways to do it but a convention has been adopted to make all Leu CG atoms look the same. If your residue is being flagged as backwards, simply edit the PDB file and swap the numbers on the two CD atoms. Some programs monitor fake chiral centers but others do not. The PDB certainly does, at least for amino acids. Check the labeling of oxygen atoms in phosphates if you want a scare. If this isn't your problem please add details. Ha! Have you been talking to Gert Vriend :) Dale Tronrud Francis E Reyes wrote: Actually i just checked my structure with the Validate - Incorrect Chiral Volumes. It seems to check out OK, but the PDB doesn't like it? Anyone? thanks FR On Mar 5, 2009, at 4:25 PM, Francis E Reyes wrote: Hi all, Just tried to submit a PDB and it seems that LEU is not correctly positioned (CG/CD1,CD2). I real space refined this residue, does the real space refinement take into account stereochemical considerations? Thanks FR
Re: [COOT] Feature Request: Notes
Dear Dirk, David, 2009/3/11 Dirk Kostrewa kostr...@lmb.uni-muenchen.de: Dear Paul, this is a feature request: I would like to attach notes to the structure, like water or sodium, alternative conformation?, peptide flipped, that should be displayed in the next session like labels as a three-dimensional notebook of what I've already done or want to do. There is place-text to do this. That has been available since Coot 0.0. This can be very useful, especially to avoid perpetual re-fitting/omitting of the same feature again, or simply to mark checkpoints. It should be possible to put a note both at an atomic position or at the pointer position (to mark unexplained density for instance). The notes could be saved with the session file or as an external file that could be read into a new session. Could you please think about adding this feature? David Briggs wrote: Seconded! That is a fantastic idea - so essentially a label associated with a feature a set of co-ordinates. This is exactly what annotated view labels are. This has been available since 0.3.2. Or am I missing your point? (View descriptions are displayed in the views panel - not in 3D). You can add view descriptions using (add-view-description view-number text) Kevin Cowtan wrote: Hmmm... Could probably be done with MMDB's UDD records. Then notes would be attached to atoms (maybe residues?). THis has the advantage that if you move the module to a different asymmetric unit you retain the comments. It might be nice to save them in the PDB file as remarks, but while I think recent MMDB can read remarks, I'm not sure if it can write them? Also relevant to future PDB spec. If text is attached to residues/atoms then that is quite involved - how do you transfer annotations from one molecule to the next? (as you would surely want to do after cycling with Refmac). This is not unsolvable, just needs to be thought about so that it happens is as slick a way as possible. (Yes, it would be nice if after Refmacing (or as you suggest, Phaser, say) annotation remarks were transfered to the refined molecule). If text is attached to a position in space there is no issue of transferring annotations and you can use place-text. Attached is a simple piece of code to do that where I add a gui wrapper to place-text so that you can make a 3D annotation, and save and load those annotations. Regards, Paul.
Re: [COOT] ProDRG cif file for coot-dirty mmcif
Sangeetha Vedula wrote: I get the dirty mmcif message in the terminal window. This is the message I get: dirty mmCIF file? /Users/.../r-pento.cif Bad CIFRC_Ok on ReadMMCIFFile init_refmac_mon_lib /Users/.../r-pento.cif had no bond restraints For the record, It turns out that this was a DOS-Unix conversion issue. I am reminded to make the error output more verbose than simply dirty cif. I've made a note. Thanks, Paul.
Re: [COOT] display manager window
Frank von Delft wrote: I dont know which version of Coot you use, but usually you can move the separator between the maps and molecules up and down (indicated by a few dots under the map bottom scroll bar). In this way you can make the space you want. Well, I second the request: it could auto-size, and save me a few annoying mouse-click-and-drags. Noted. While we're at it: the text boxes don't resize sensibly when you drag the window wider -- I forget what it does (actually, I can't figure it out), but it is totally non-intuitive and hides buttons and things. (May not be easy to fix, I realise.) That will go away in the Great Display Manager Redesign. Also, I think that a button in the display manager by which one could control wether or not the molecule's symmetries are visible would be very nice. We could think about this, however the 'Display Manager' is kind of crowded as it is and we may not want to make it worse... (N.B. we are thinking about some rework of the display manager anyway, maybe there will be space then...). Well, maybe it helps to think the other way round: little is more important than having quick and easy control of what's shown, what the colours are, how to declutter, etc etc. -- i.e. exactly the display manager. So you can hardly have that thing too cluttered: if it gives the control, all is good. OK. Btw, I thought pymol had a relatively elegant solution (although not the final word). And many commercial programs tend to have a proper tree, which I've found is the best way to do it. I don't know the commercial programs of which you speak (or pymol, come to that) but ccp4mg has a tree - sort of - and we were thinking to do something like that. Paul.
Re: [COOT] svn revision 1950 and rigid body fit zone
hari jayaram wrote: Hello , I just noticed that rigid body fit zone in revision 1950 stops expecting user mouse clicks after clicking on the first atom . Is anyone else seeing this. Hi Hari, Do you mean rigid body fit or Rotate/Translate mode? (Rotate/Translate can go into single click mode (it's designed to)). I can't reproduce the problem of rigid body fit going into single click mode Paul.
Re: [COOT] svn revision 1950 and rigid body fit zone
hari jayaram wrote: Hi paul, Kevin did write to me asking if I could submit a detailed bug report. Strangely, I could not reproduce the problem. I am still running revision 1950 ..On that day myself and one other person ( I think it was Dr Eleanor Dodson) reported that the rigid body fit zone ..was stopping after the first click. I have since used rigid body fit zone many times without any problem in rev 1950 I had two more unrelated issues. # Add terminal residue and simultaneous movement Didnt coot previously also allow you to simultaneously rotate-translate a terminal atom concurrently with the addition. I don't think so. Now in revision 1947 onwards. Clicking add terminal residue only allows you to move the atom around using the mouse . So all end residue additions are two steps , first add, then accept and then again rotate translate zone to position. Is this intended. That is a bit tedious. Try these settings: (set-add-terminal-residue-immediate-addition 1) (set-add-terminal-residue-do-post-refine 1) Also, http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/Pauls-key-bindings-for-coot Then | (bar) add a terminal residue to residue at the centre of the screen (it will add it as stars initially (bug yet to be fixed)), but a t will fix that. # Copy_from_ncs_master_to_others : creates all atoms as stars in ncs mates I don't see that :-(. Paul.
Re: [COOT] deleting coot backup directories
Simon Kolstoe wrote: Dear Cootbb, As I am a crystallographer and not a programmer, could anyone suggest a bash script that will go through my hard drive deleting all the pesky coot-backup directories with their horribly long file names that zipping software cannot cope with? Also, in a future version of coot, would it be possible to change the names of the coot-backup files to something simpler e.g. just date and time (for instance something like 240409-1650.pdb)? Not answering your question, but may be of some use: Coot looks at the COOT_BACKUP_DIR environment variable. You can set it to ~/junk/coot-backup for example and all backups will be made to there. Then you have only one directory to worry about. There are no plans for short backup file names. I don't know that gzip has any problems with coot backup file names. Paul.
Re: [COOT] 'Isolate' Coot's Python2.6 from Ubuntu system
Victor Alves wrote: Dear all I installed Coot with Python and GTK2 in Ubuntu Intrepid 8.10. Ubuntu 8.10 has Python 2.5. Since 'ccp4-others.setup' file points to Coot's directory when I check 'which python' I get version 2.6 (the one Coot provides). Is there a way to isolate Coot's python from Ubuntu system but still maintaining the ability to call Coot from the terminal? So that Ubuntu's Python version would be the active one for all the system (except for Coot)? Dear Victor, Thank you for reporting this problem. It is not unreasonable for ccp4's setup to add the coot binary directory to the path. However, (as you have noted) Coot adds its built-in python to this directory - and we do that deliberately (but I don't see why, currently). You could try to remove python, python-2.6, python-config and python-2.6-config from that directory and coot should still work fine. Please try this out and let us know if there are problems, I will remove their addition to the binaries if there are not. (Of course, Kay's solution also works - and I do something like that myself, which is why I have not seen this problem). Regards, Paul.
Re: [COOT] Coot versions
Kay Diederichs wrote: Victor Alves schrieb: One other question. In this link, http://www.ysbl.york.ac.uk/~emsley/coot/build-info Should I not use any builds which are red? What about the size of the green bar? from quick inspection I would guess that green bars mean built less than 24 hours ago and red bar more than 1 day old. That's right. Because the builds happen every night [1] the colours are a hint to us that something may have gone wrong in the daily/nightly builds. I have been thinking about reworking this page, because now that it is used by users (not just developers) it is problematic that a big red bar sometimes represents a quite recent build (as the comment from Victor suggests). Paul. [1] actually, there are exceptions, which make things non-straightforward.
Re: [COOT] [ccp4bb] Watertidy troubles
Andrii Ishchenko wrote: You can do this using coot. Just switch on showing symmetry mates(menu Draw-CellSymmetry). Then save the needed by Save Symmetry Coordinates Option in menu File. Waters coordinates will be saved as well. [changing bbs] And just for the record, the function that David Borhani wanted, i.e. move the waters so that they are around my protein has been already requested by Garib Murshudov and is slated for 0.7. Paul.
Re: [COOT] monomer DB
Justin Lecher wrote: Hi all, what is the difference between the monomers db which is provided by coot and the one which is provided by refmac/ccp4? Can one interchange them? Coot uses the Refmac dictionary. As far as I know, there should be no differences. Yes, they are interchangeable. Coot will in preference use the CCP4 distribution Refmac library, and only if there are no other options, will it fall back to using its own copy. Yes you can change them. Paul.
Re: [COOT] DNA mutation
Pierre Aller wrote: On Apr 7, 2009, at 2:37 PM, William G. Scott wrote: Looks like you might be mutating into RNA (hence the non-canonical little r). But that is ok. RNA is inherently more interesting. On Apr 7, 2009, at 10:48 AM, Pierre Aller wrote: Hi all, I am using the last version of coot on mac OS X. I tried to mutate some nucleic acids and I encounter some problems. It works fine for everything except for a mutation toward a Thymine. I got this error message: This should never happen - badness in get_standard_residue_instance, we selected 0 residues looking for residues of type :Tr: Oops - can't find standard residue for type Tr Hi Pierre, Thanks. As of revision 1965, I believe that this issue is fixed (it was a typo in the generation of the canonical base name (it checked for RNA twice)). Regards, Paul.
Re: [COOT] Feature Request(s)
Dear Oliver, Antony Oliver wrote: Dear Paul + friends, Would it be possible to place in the (top right?) corner of the main screen (or elsewhere) an indicator telling the user what type of restraints are currently being used for real- space refinement/fitting? I frequently forget that I have put alpha helix restraints on when building, and wonder why my amino acids are drifting so dramatically out of my electron density! We were talking about this problem just recently (at the CCP4 dev meeting, I think). Yes an iconic indicator would be nice. What would be more clever, we think (or at least I think we think) is for Coot to realise that helical (or strand) restraints are active and examine the helicalness (strandiness) of the fragment that you are trying to refine - and if it passes a threshold of sufficient difference from ideality then you get a warning - something along the lines of an Are you sure? dialog. I think it would also be useful if something similar could also be displayed to indicate which map you are using for fitting and refinement - I often have 2fo-fc maps, fo-fc maps, and ncs-averaged maps loaded - and often have to switch between them when building - and frequently forget which one I am currently using. Yes, OK. For 0.7. And, speaking of NCS I would really appreciate a script that could superimpose a selected molecule onto all the ncs-related molecules and write them all out to a PDB. I currently do it manually, by SSM Superpose, change chain ID, and writing out to PDB. Which is fine when you only have two or three molecules in the asymmetric unit, but when you have more... The copy-chain function is supposed to do something very like that. If by selected molecule you mean Coot's NCS master chain, then copy-chain is what you want (Extensions - NCS - Copy NCS chain...). If the selected molecule is not part of NCS molecule, you will have to do a bit of massaging. Paul.
Re: [COOT] Feature Request(s)
Antony Oliver wrote: Paul Emsley wrote: Dear Oliver, Antony Oliver wrote: Dear Paul + friends, Would it be possible to place in the (top right?) corner of the main screen (or elsewhere) an indicator telling the user what type of restraints are currently being used for real- space refinement/fitting? I frequently forget that I have put alpha helix restraints on when building, and wonder why my amino acids are drifting so dramatically out of my electron density! We were talking about this problem just recently (at the CCP4 dev meeting, I think). Yes an iconic indicator would be nice. What would be more clever, we think (or at least I think we think) is for Coot to realise that helical (or strand) restraints are active and examine the helicalness (strandiness) of the fragment that you are trying to refine - and if it passes a threshold of sufficient difference from ideality then you get a warning - something along the lines of an Are you sure? dialog. Great- although I have to say Are you sure? dialogs are an evil that should be avoided - they drive me mad! (the Undo is sufficient!) OK, better would be Use Helical Restrains when refining this? Yes No. Paul.
Re: [COOT] coot dependency on $LANG?
Steffen Schmidt wrote: Hi, I experienced a weird error (amino acids are not connected) when setting the environmental variable LANG to de_DE.UTF-8 (on a OS X 10.5 machine). I guess this language setting is screwing up the PDB file parsing since german uses ',' as decimal separator… Correct.
Re: [COOT] coot dependency on $LANG?
William G. Scott wrote: Could you (or we) set LANG=en_US.US-ASCII in the coot wrapper script? or unset LANG I am more than a little surprised that such a thing is not there already. I'll add it now. Paul.
Re: [COOT] problems of version 0.6
Leonid Cherney wrote: I tried today the new version (-0.6) and see some problems. 1. Simple mutate for nucleotides. The program makes Gr, Cr etc. in DNA (should be Gd, Cd etc). And it does not mutate to thymine at all, because there is no Tr. Where can I say that it's a DNA? This has been fixed up recently - or so I believe. Please let us know the revision number. The output of $ coot --version is useful for us. 2. Where is pukka puckers...?? withdrawn due to a coding error. It should be straightforward to fix, but as yet has not been. Paul.
Re: [COOT] RSR exploding RNA
CK wrote: I think perhaps I should clarify what I've been doing. I've been refining my structure using phenix.refine and had reached a fairly satisfactory point with suitably low R-factors (21/25) and very reasonable RMSDs for bonds and angles. At this point I ran my structure through the molprobity server to take a closer look at geometry and clashes. OK, so that's the issue, right there. Molprobity is a modern program - using PDB v3 atom names. Coot uses the Refmac dictionary, i.e. version 2.3 names. Coot does not recognise the new atom names e.g. C1' (in Ar) or HB3 (in ARG) and so pushes them out with non-bonded contact restraints. If you want to use the output of molprobity with coot/Refmac dictionary, then you will need to downgrade the molprobity output file. Yes, this needs to be fixed - upgrading and validating the new dictionary is a substantial task. For the record, Coot ignores the occupancy of the atoms when refining. Adding hydrogens to a model should do reasonable (if not good) things no matter the resolution of the data. As going through the entire clash list by hand can be very tedious I wanted to see if adding hydrogens in the riding positions and refining again would help alleviate some of the clashes, which it did. Yes, it should. Paul.
Re: [COOT] more suggestions - sorry
Dear Eleanor, Eleanor Dodson wrote: 1) The check on GLN and ASN and HIS? for likely hydrogen bonding is very useful. Do you think it would be worth extending this to THR? HIS is not part of the ASN/GLN check. And indeed the ASN/GLN check works by B-factor analysis, not hydrogen bonding. For hydrogen bond checking, I use reduce. (Once can also use What_check, but the support for that is not so good). I do not think the algorithm in Coot is suitable to extend to THR. 2) The Ramachandran plot includes residues with zero occupancy - it would help if they were flagged somehow differently.. I see. Thank you. This is duly noted (along with your prior request to show the Ramachandran plot of only a selection of residues). Paul.
Re: [COOT] merge water chains
From: Christian Roth christian.r...@bbz.uni-leipzig.de Hi all, I am not sure but If I remember correctly Bernhard mentioned on the last CCP4 study weekend in Nottingham that Coot is able to merge the different water chains, generated through repeated refinement runs, in one. If this function exist, how can I use it? Thanks in advance for your help. Bernhard Lohkamp wrote: Since I supposedly mentioned this (and I have made a script)... there is a python function to do so: use merge_solvent_chains(imol) or merge_water_chains(imol) alternatively you have to do it by hand, i.e. using Calculate-Change Chain ID (use residue range). B P.S. no corresponding scheme function there yet. As of revision 1980, there is a scheme version. Both this and the python version renumber the waters as they merge them. Paul.
Re: [COOT] problems of version 0.6
Maia Cherney wrote: The general torsion function is not as good as the torsion in old X-fit. Are you or have you ever been a member of the von Delft Pressure Group? In x-fit you click on two atoms of a single bond and you can rotate the rest of the molecule around that bond. This bond can be in the middle of the main chain etc. It's a very useful function, if you need to rotate a polypeptide around a single bond. Are you planning to do a similar thing? Yes - we intend to have that before version 1.0. Paul.
Re: [COOT] subversion build on ubuntu 9.04 fails : [: =: unary operator expected error
hari jayaram wrote: Hi ..I tried a coot subversion (revision 1994) built-it-simple python on the newest ubuntu 9.04 The build crashes just after it builds guile and ( 16-coot.txt in the build directory ) reads : checking for Clipper... yes Congratulations, you are using Guile checking for guile... no configure: error: guile required but not found ./build-it-gtk2-simple: line 2742: [: =: unary operator expected NO need to update libtool /home/hari/autobuild/ex-charlie_2009-05-08__T20_14_49/coot-0.6-pre-1 make: *** No targets specified and no makefile found. Stop. This happens only on the new ubuntu (on a 32 bit 9.04 system) . I was able to build this revision without any problem on Ubuntu 8.04 64 bit Thanks update_libtool is not set sometimes, so using it as in 1994 is wrong. I've tweaked the script. But the problem for you lies above that.. checking for guile... no configure: error: guile required but not found Hmm! what went wrong there..? I'll try to build from scratch on Jaunty myself. Cheers, Paul.
Re: [COOT] ELFCLASS64
Ed Pozharski wrote: After recent upgrade to Ubuntu 9.04, coot binaries that worked fine before started reporting the ELFCLASS64 error when loading a particular library, namely /usr/lib/libguile-srfi-srfi-1-v-3.so.3. I understand that the real root of this problem is my bizarre obsession with installing 64-bit Linux and then being too lazy to compile coot from source and instead trying to use 32-bit coot binaries. To resolve the ELFCLASS64 issue, I downloaded guile1.8 32-bit debian package from ubuntu repositories and placed libraries into /usr/lib32. That, of course, didn't help and I had to redirect the symbolic link in /usr/lib to /usr/lib32. Now coot runs fine, but this is an ugly fix, not to mention that it may cost me down the road when some 64-bit application discovers that I substituted the library. At the same time, I see that $COOT_PREFIX/lib contains all the libraries, and so my question is why coot tries to load libraries from /usr/lib? Should I uninstall guile via synaptic (I am not sure why I installed it in the first place)? Very curious. AFAIU the libguile-srfi-srfi are loaded at runtime (probably for some string function). I would have thought that they should load from the installation directory (rather than the system one). How curious. (And, yes, it is ugly.) Well, I'll be over your way in a couple of weeks, if we don't get it sorted out now, we should try to find some time then. Paul.
[COOT] mouse buttons and arrow keys [was Re: problems of version 0.6]
Dear Maia, Maia Cherney wrote: I would like to use only one-button keys, so that I could use only one hand when fitting. Why!? Because the other one is needed to prop up your head, maybe? :-) http://linuxoutlaws.com/files/dan-jaunty-party-thumb.jpg I find using my left hand for keyboarding makes things way faster than clicking on icons with the right hand on the mouse. Well, now help me with key-bindings, please. I need one or two buttons on the mouse for map dragging. Pymol and x-fit use the middle button for translation. It confuses me all the time, when I work in coot after working in pymol. Do you have any unused two-button combinations on the mouse? If it's not possible to touch the mouse buttons in the key-bindings, please help me to program arrow key for translation. Could you give me a script for that, I can't write it myself. There are no two-button combinations (chording) on the mouse. I have avoided them so far - it seems an esoteric interface and there have been better ways of providing the necessary functionality. Middle mouse drag for translate could be enabled as an option, I suppose. As for the arrow keys for translate, add the following to your ~/.coot file. You might need to tweak zsc. Be slightly careful not to overly dwell with you finger on the button if you do not have a fast processor/graphics card and have a fast key repeat. Paul. (let* ((zsc 0.02) (screen-coords-nudge (lambda (tvm nudge ori) (map (lambda (e) (* nudge (apply + (map * e ori tvm))) (f (lambda (axes) (let ((nudge (* (zoom-factor) zsc)) (rc (rotation-centre)) (tvm (transpose-simple-matrix (view-matrix (apply set-rotation-centre (map + rc (screen-coords-nudge tvm nudge axes))) (add-key-binding Translate UpUp(lambda () (f '(0 1 0 (add-key-binding Translate Down Down (lambda () (f '(0 -1 0 (add-key-binding Translate Left Left (lambda () (f '(-1 0 0 (add-key-binding Translate Right Right (lambda () (f '( 1 0 0)
Re: [COOT] Scheme on WinCoot (Win XP)
Alex Luso wrote: Hi Bernhard, Thanks for the clarification. commenting on this. Maybe there should be some low level implementation without the use of fancy (scheme) widgets, so that at least scripts can be run.. (on my - long - list now). Ok, I think that would be a good idea. Given the fact that almost all scripting examples on the manual and in various other scripts in this forum are written in scheme it would be nice to have access to at least the basic scripts (non-gui) without having to resort to re-writing them in Python. Almost all fancy scheme scripts have a fancy python counterpart (somewhere). In cases where that is not so, such a counterpart can often materialize if desired. Although the rules for how to convert scripts are documented, it's still a hurdle, especially for non- programmers. Yes, that is true for anything other than the most simple/trivial customizations. About the underlying problem - the text in scheme widgets - is that a missing feature in the Windows scheme libraries or some weird bug? Can you be somewhat more precise in you description of the text in scheme widgets? Paul.
Re: [COOT] Zinc-density
Moritz Metlitzky wrote: Hi everybody, i just installed coot and played around a bit with my structure and the Fit Protein command. Now to my question, i have a zinc atom in my structure coordinated by 3 cysteines. it refines pretty well, but when i do Fit Protein Coot always links the 3 cys directly in the zinc density, so it seems it doesn't know that a zinc is there. it is displayed as zinc and everything but it doesn't assign density to it. The trick in such a case is to change the map to which you are fitting. You should mask out the Zincs in the map. (It should be possible do select by element but how to do that escapes me for the moment (it is an mmdb atom selection string)). So probably fastest to do it by residue number: //B/23-25 or so. Then used the masked map as the refinement map of course. Paul
Re: [COOT] Ubuntu Jaunty (9.04) subversion build works great now
hari jayaram wrote: Hello Paul and everyone, Since I had complained about difficulties in building coot from subersion on Ubuntu Jaunty , I thought I should write in to say that I tried building the subversion revision 2021 on ubuntu 9.04 from scratch and it builds just fine and everything works great 2021 has interactive sharpening - enjoy :) However the build-it-gtk2-simple python build script seems to always build into two directories the : $AUTOBUILD_BUILD/coot-pre-release-gtk2-python AND $AUTOBUILD_BUILD/coot-Linux-i686-ubuntu-9.04-gtk2-python Technical answer: IIUC, the build script builds coot and dependences and dev files in $AUTOBUILD_BUILD/coot-pre-release-gtk2-python. At the end the build script copies (rsyncs) out a minimal portion the built files. You don't need the include files to run coot (this cuts down the binary tar ball size and was suggested by Clemens Vonrhein). Being in a different directory to the one in which it was built simulates being installed on another computer - and thus we (also) run the test suite from there (which has caught a few problems in the past). For my 32 bit 9.04 running ubuntu the coot-pre-release-gtk2-python/bin/coot binary works just fine . Good. The coot-Linux-i686-ubuntu-9.04-gtk2-python/bin/coot stops with a message (GThread-ERROR **: GThread system may only be initialized once.). Is that because it may be a 64 bit build? No, well, not fundamentally - it seems to me that a bug is being tickled but only in the 64 bit version. I wonder (to myself) if it is because both scheme and python are setting up threads... So I am guessing I have to give some command line switch to the script to suppress the i686 build on this ubuntu 32bit 9.04 box. No... not really... (i686 is the default, isn't it?) you can set the arch type in the compiler flags if you want, but that is not a proper solution. Regardless I am happily cooting with the latest build on Jaunty jackalope. Thanks a tonne :-) Paul.
Re: [COOT] coot does not read sg info in cns files
Sebastiano Pasqualato wrote: Hi Paul, hi all. I have noticed that coot can't deal with spacegroup information of cns files. I have to substitute this: CRYST1 87.188 49.276 132.627 90.00 108.88 90.00 P 21 with this: CRYST1 87.188 49.276 132.627 90.00 108.88 90.00 P 1 21 1 to have the symmetry displayed properly. Could you make coot be able to read the cns format too, I'll think about it. or is there a script that handle this? ;; This will force P 1 21 1 down the throat of all model molecules ;; whose space group is unknown. (map (lambda (n) (if (string=? (show-spacegroup n) No spacegroup) (set-space-group n P 1 21 1))) (model-molecule-list)) Paul.
Re: [COOT] symmetry operator generation on COOT
Hi Jennifer, Doebbler wrote: I am running Coot 0.5.2 on an intel Mac 10.5.6. I am trying to visualize the symmetry related molecules for a small inorganic molecule in spacegroup P 21/C. If I load the file into swiss PDB viewer or Mercury, the symmetry operators show that I have 4 molecules in my unit cell and a pretty orderly looking packing scheme. Coot, however, does not seem to like the P 21/C spacegroup. I changed the CRYST1 line to read CRYST1 25.0006.082 11.308 90.00 100.04 90.00 P 1 21/c 1 Indeed. That is what I would have done. The space group symbol in the PDB file should match the xHM symbol in syminfo.lib If I go to Draw-cell and symmetry- master switch: show symmetry related atoms- yes I get a very cramped unit cell with many more than just 4 molecules within. Well that is a surprise. You should definitely only see 4. Cramped as in crowded I presume you mean. I imagine that Coot at least got the cell correct. (I presume (because of your scripting competence) that it wasn't something trivial like inadvertently displaying the symmetry for other molecules also) I tried to ask coot what it thinks my spacegroup and symmetry operators were to reconcile this result with those of mercury and swiss viewer. It recognizes the spacegroup as P 1 21/c 1. coot (show-spacegroup 0) P 1 21/c 1 As it should be. If I then ask coot to show-symmetry I get the following coot (show-symmetry 0) Backtrace: In current input: 8: 0* (show-symmetry 0) unnamed port:8:1: In expression (show-symmetry 0): unnamed port:8:1: Unbound variable: show-symmetry ABORT: (unbound-variable) :-( There is no command to output the symmetry operators. I'll make a note to add one. I'm stumped - I don't know what is going on. If you have a shelx .ins file for this molecule, I'd be curious to know if it was displayed correctly. Paul.
Re: [COOT] symmetry operator generation on COOT
For the record/archive I'd like to conclude this thread. It recognizes the spacegroup as P 1 21/c 1. Is seems that Coot indeed does display symmetry correctly for this spacegroup, but not in the way that other programs (e.g. Mercury or Swiss PDB Viewer) do. coot (show-spacegroup 0) P 1 21/c 1 If I then ask coot to show-symmetry I get the following coot (show-symmetry 0) Backtrace: In current input: 8: 0* (show-symmetry 0) unnamed port:8:1: In expression (show-symmetry 0): unnamed port:8:1: Unbound variable: show-symmetry ABORT: (unbound-variable) You followed the instructions in the manual. I am sorry to say that there is a error there, it should have (and now does) read: (get-symmetry imol) Thanks, Paul.
Re: [COOT] Problem with coot
Oliv Eidam wrote: Hi, I have the same problem like Robert. And although I updated to coot-0.6-pre-1-1941-intel-10.4-10.5.tgz like Bill suggested, the problem (displaying no or wrong bonds) persists. Has this problem been resolved by now? I am using OSX 10.4.11. And source /sw/bin/init.sh was not the answer? Check the settings of LANG, LANGUAGE LC_NUMERIC is what I suggest. Paul
[COOT] Coot with phenix.refine and buster output
Dear Bleeding-edge binary [1] Coot users, I would appreciate feedback on the representation of LINKs using the output of Buster and Phenix.refine. (The last time I saw this in action (I don't have such files myself) (and prior to the most recent fixes) it crashed.) Thanks, Paul. [1] rev 2037 or later
Re: [COOT] Coot fails to read numeric chain IDs
Edward Miller wrote: Hey Folks, I'm working on refining a full capsid containing 60 chains. Using the chain ID column, I've numbered my chains A-Z, a-z, and 0-7. I was successfully able to refine my capsid in refmac using this chain ID naming scheme. However, coot fails to read in any of the chains labeled 0-7. I don't know why this is failing - I will try to make a synthetic PDB file with 60 chains to see if I can reproduce this. Relatively recently Eugene has extended mmdb to work with the hybrid_36 format. So for now you could go that route. Paul.
Re: [COOT] Coot fails to read numeric chain IDs
Kevin Cowtan wrote: Coot reads files with duplicate atom numbers just fine (at least 0.6pre-latest does). However Coot will ignore any lines beginning ATOM 1? ATOM 2? etc because those are not valid atom records. So that is the reason these are being ignored. Yes, we should say that this is handled by the mmdb library from Eugene Krissinel. The original poster could have expedited the analysis somewhat by quoting the console log which should have reproduced the problematic lines and line numbers. Paul. (p.s. back now, less out of touch)
[COOT] Friday afternoon distraction...
http://thedailywtf.com/ 2009-06-11 (I never get to see that dialog, of course :) (Somehow they've got the mac version of this - apparently they don't fink update-all often enough...) Paul.
Re: [COOT] crash upon sequence display
Valerie Biou wrote: I run Coot version 0.6-pre-1 on a Macbook Pro. I used the fink installation. It crashes when I ask it to display a sequence ** (coot-real:764): WARNING **: Widget not found: sequence_view_dialog /sw/bin/coot: line 5: 764 Bus error /sw/bin/coot-real $@ I must admit that, at least last time this happened, the sequence window for this structure was already open somewhere when I asked for it a second time. But there are so many windows.. This seems to be reproducible. Dear Valerie, Yikes, that was a nasty one. Thanks for this feedback (and providing the problematic file). It turns out that I was using an unsigned int for dealing with residue numbers in the sequence view (silly me). Your pdb had negative residue numbers (There was also problems dealing with both the new-style and old-style sequence views). Fixed in revision 2062. Thanks, Paul.
Re: [COOT] Novel maps...
Simon Kolstoe wrote: Dear cootbb, When building into density I use a map generated from the FWT amplitudes column and PHWT phases columns which I think is my 2Fo-Fc, and a second map generated from DELFWT and PHDELWT which I think is my Fo-Fc. Me too (more or less). This keeps me happy and in known territory. However today someone in the lab asked what it means to generate a map using FWT and PHDELWT. Not much. Does anyone know what type of map this would be in the Fo Fc terminology? A mistake. Actually, the PHWT and PHDELWT are related. AFAIU, somewhere in Refmac there is something like this: if DELFWT 0: DELFWT = - DELFWT PHDELWT = 180 + PHWT else: PHDELWT = PHWT
Re: [COOT] to separate levels of positive and negative density
Maia Cherney wrote: If I use a *map_coeffs.mtz file from the phenix.refine, how can I turn off the negative density? ??? Confusing question. By unclicking the is difference map? button (you can't do this in auto-read mode, of course). Paul.
Re: [COOT] Novel maps...
Maia Cherney wrote: Hi all, Is it possible to change residue or atom occupancies in coot? Maia Yes. http://www.ysbl.york.ac.uk/~emsley/coot/doc/chapters/user-manual_5.html#SEC147
Re: [COOT] font issue specific to ppc
William Scott wrote: Hi Paul: On ppc but not intel, I get this for some of the window displays (eg density fit analysis): Yes, we (in Oxford) have seen this before on ppc too. We didn't resolve it. I was thinking that it was somehow picking up the wrong fixed font. I tried adding a font path with a new font aliases and an xset +fp dir, but that didn't work. I don't recall the current state. Will investigate when back at work. Paul.
Re: [COOT] Mac version of coot
William Scott wrote: I guess I'd better brew something newer up... All the 0.6 are pre-releases ... Yes, indeed (I finger fumbled and posted before I added the sentence to that effect). Paul.
