Re: [COOT] Structure factors to CCP4 maps
I am terribly sorry, but ccp4 maps are understandable to nobody. They are binary files, for starters. Even if you develop an uncanny ability to read these you will still be left with random looking sea of numbers. If you trying to generate a model map, you can use sfall. Given that you are posting on coot bb, the easiest way to visualize such map is to use Fc column from, say, zero step refmac run. Be more specific. Look at pdb_redo, it may be what you are looking for. Sent on a Sprint Samsung Galaxy S® III div Original message /divdivFrom: RiC patrick.coss...@inbox.com /divdivDate:05/27/2014 4:42 PM (GMT-05:00) /divdivTo: COOT@JISCMAIL.AC.UK /divdivSubject: Structure factors to CCP4 maps /divdiv /divHI, Does anyone have a step by step guide to go from a structure factor file from the PDB to a CCP4 map (understandable to a biologist) like the one I can download on the electron density server? I am confused and my attempts at using CCP4 keeps coming up with failed Thanks Patrick FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more!
Re: [COOT] Structure factors to CCP4 maps
In most cases, cif file you can download from the PDB doesn't contain map coefficients. You need to specify which map you're trying to visualize. If it's model map (fo? fc?), you can calculate that using sfall. If you are trying to check the electron density (2fo-fc), you need to add bulk solvent correction at the very least. You can use refmac to do that (zero cycles if you don't want the model to move) or better yet get it from pdb_redo. There is coot plugin there and maps are precalculated. Coot reads output mtz files from all major refinement programs. No need to calculate the ccp4 map. Sent on a Sprint Samsung Galaxy S® III div Original message /divdivFrom: RiC patrick.coss...@inbox.com /divdivDate:05/27/2014 5:36 PM (GMT-05:00) /divdivTo: Ed Pozharski pozharsk...@gmail.com, coot@jiscmail.ac.uk /divdivSubject: RE: Structure factors to CCP4 maps /divdiv /divI am NOT trying to open the CCP4 file on a text editor ! I am trying to do the following on CCP4/COOT: 1) Download a PDB (example 1c75.pdb) from the PDB database 2) Download the corresponding structure factors (example 1c75-sf.cif.txt) 3) Now from the above sf-cif file How can I get a MTZ file using CCP4 4) Then display the map (either in CCP4 format or MTZ format) in COOT I want to know how to do step 3 above. Sorry, I was not more clearer earlier. Patrick -Original Message- From: pozharsk...@gmail.com Sent: Tue, 27 May 2014 17:31:47 -0400 To: patrick.coss...@inbox.com, coot@jiscmail.ac.uk Subject: RE: Structure factors to CCP4 maps I am terribly sorry, but ccp4 maps are understandable to nobody. They are binary files, for starters. Even if you develop an uncanny ability to read these you will still be left with random looking sea of numbers. If you trying to generate a model map, you can use sfall. Given that you are posting on coot bb, the easiest way to visualize such map is to use Fc column from, say, zero step refmac run. Be more specific. Look at pdb_redo, it may be what you are looking for. Sent on a Sprint Samsung Galaxy S® III Original message From: RiC Date:05/27/2014 4:42 PM (GMT-05:00) To: COOT@JISCMAIL.AC.UK Subject: Structure factors to CCP4 maps HI, Does anyone have a step by step guide to go from a structure factor file from the PDB to a CCP4 map (understandable to a biologist) like the one I can download on the electron density server? I am confused and my attempts at using CCP4 keeps coming up with failed Thanks Patrick FREE ONLINE PHOTOSHARING - Share your photos online with your friends and family! Visit http://www.inbox.com/photosharing to find out more! Free 3D Earth Screensaver Watch the Earth right on your desktop! Check it out at www.inbox.com/earth
Re: [COOT] Structure factors to CCP4 maps
If you want to know what EDS does, read here http://eds.bmc.uu.se/eds/eds_help.html#NITTY_GRITTY It does, indeed, run refmac to get bulk solvent and anisotropy corrections. Sent on a Sprint Samsung Galaxy S® III div Original message /divdivFrom: Alejandro Buschiazzo ale...@pasteur.edu.uy /divdivDate:05/27/2014 6:49 PM (GMT-05:00) /divdivTo: COOT@JISCMAIL.AC.UK /divdivSubject: Re: Structure factors to CCP4 maps /divdiv /divyou're absolutely right. (mostly so, given these are questions to the coot bb :) ) Just one comment, and one question, if I may: 1.Comment: sometimes it's just a good idea to know what are you actually calculating, so a bit better to dig deeper in the files that you use, and get to the point where you need to choose for instance which coefficients to use etc. Especially for beginners (e.g. bad idea to look at a [Fcalc;PHIcalc] map...the map will look gorgeous ;) so on and so forth) 2. Actually this example is interesting, to learn a bit more about what is it that Coot is actually doing when invoking File - Fetch PDB Map using EDS It works indeed fine. If I go to EDS however, because of too high a disagreement on Rfactors, it actually doesn't enable me to get anything at all (am I missing something here?) And, going to the source, in the PDB entry 1C75, the deposited structure factor file, only includes observed amplitudes (and sd's) for measured reflections. My question: closing coot after fetching the EDS entry (coot IS able to get something from EDS!?), if you look at the coot-download dir, you can find an mtz with many columns, including sigmaA-weighted amplitudes and phases for 2fo-fc anf fo-fc fourier (a la Refmac) so, as Ed suggested, I guess coot is performing a 0 cycles refmac behind the scenes? or is it doing something else? wouldn't it be good to have also the original sf file saved in the download directory? thanks ale On 5/27/14, 19:07, Bernhard Lechtenberg wrote: Hi all, I might be missing something here, but in Coot, can you not just use File - Fetch PDB Map using EDS… to get both the model and the map? This definitely works for me for your example 1C75. Bernhard Bernhard C. Lechtenberg, PhD Postdoctoral Fellow Riedl Lab Sanford-Burnham Medical Research Institute 10901 North Torrey Pines Road La Jolla, CA 92037, USA Phone: 858.646.3100 x 4216 Email: blechtenb...@sanfordburnham.org -- Alejandro Buschiazzo, PhD Research Scientist Unit of Protein Crystallography Institut Pasteur de Montevideo Mataojo 2020 Montevideo 11400 URUGUAY Phone: +598 25220910 int. 120 Fax: +598 25224185 http://www.pasteur.edu.uy/pxf
Re: [COOT] Atoms with zero occupancy
Yes, it would certainly be helpful. Sent from my Galaxy S®III Original message From: Eleanor Dodson eleanor.dod...@york.ac.uk Date:01/14/2014 10:12 AM (GMT-05:00) To: COOT@JISCMAIL.AC.UK Subject: Atoms with zero occupancy I would like the coot option - find residues with missing atoms to at least have the option to pick those residues where there are atoms with occupancy set to 0.00. Do others feel this would be helpful? Eleanor Dodson
[COOT] dna restraints
Is there some non-convoluted way to force Watson-Crick hydrogen bonds during real space refinement? And a related question - is there some way to define secondary structure (helices/sheets) for the whole molecule (maybe based on header) and then enforce it? One way I see right now is to supply LINK records (which I assume coot will honor but I may be wrong) for every hydrogen bond that defines secondary structure. It would also probably require adjusting parameter files to provide distance restraints? That would take some scripting, which is no big deal. But I don't want to invent something that coot may already have a tool for. This stuff may be useful at low resolution, which is pretty much what one generally gets with protein-DNA complexes. Cheers, Ed. -- Coot verendus est
Re: [COOT] ANISOU error when atom number exceeds 99999
Correct solution to this would be to standardize tls records. Current PDB policy creates ambiguity that can only be resolved by looking for tls record in the header. So how exactly is the need to analyze header tls record avoided? ANISOU records should only be used when individual Uij's were actually refined. As a pre-clarification, to my taste there is no value in exactly reproducing R-values. Cheers, Ed. Original message From: Nat Echols nathaniel.ech...@gmail.com Date: 04/21/2013 1:20 AM (GMT-05:00) To: COOT@JISCMAIL.AC.UK Subject: Re: ANISOU error when atom number exceeds 9 On Sat, Apr 20, 2013 at 6:51 PM, Jinzhong Lin lith...@gmail.com wrote: On 04/20/2013 09:03 PM, Ethan A Merritt wrote: I really disapprove of the idea of writing out ANISOU records to describe TLS refinement. Notwithstanding the fact that the PDB recommends this, I strongly suggest that you tell refmac_not_ to write out ANISOU records. The TLS model is adequately described in the header, the extra ANISOU records are a less good way of describing the same thing. This would make sense if there was a standardized format for TLS which all programs that might care had implemented - which there isn't, as far as I know. As a result there are many entries in the PDB whose TLS records cannot be easily interpreted. A further problem is that not every program outputs REMARK records where TLS information is usually dumped, but most will preserve ANISOUs. Finally, most molecular graphics programs don't have an option to visualize TLS parameters, but most do support anisotropic ellipsoids. I agrees with you. But I am using phenix for the refinement, unfortunately there is no option for it not to write the ANISOU records. Since I assume you don't actually care about the ANISOUs for the purpose of adjusting your model in Coot, I suggest this: grep -v ANISOU model.pdb model_iso.pdb You're going to start the next round of refinement with higher R-factors than if the ANISOUs were left alone, but in my experience they'll usually recover if you run TLS refinement again. -Nat
[COOT] moving a piece of DNA
Say I have 5bp long stretch of double helix DNA that I want to dock into the density manually. Rotate/translate zone does not work, presumably because the fragment is made of two chains. I can get around this by renumbering one of the strands and then renaming it all as one chain, but boy this is an ugly workaround. I suspect I am missing something simple - is there an option to, say, move the whole molecule or a zone that spans multiple chains? Cheers, Ed. -- Coot verendus est
Re: [COOT] moving a piece of DNA
Got it, thanks. Just as I thought, it is something obvious I was missing. Worthy of rtfm comment, or its modern avatar, lmgtfy. I could try to get out of this embarrassment by claiming that the little arrow is obscure, but then I have found it right away once started looking. Thanks! Ed. On Fri, 2013-03-15 at 18:30 +, Paul Emsley wrote: On 15/03/13 16:39, Ed Pozharski wrote: Say I have 5bp long stretch of double helix DNA that I want to dock into the density manually. Rotate/translate zone does not work, presumably because the fragment is made of two chains. I can get around this by renumbering one of the strands and then renaming it all as one chain, but boy this is an ugly workaround. I suspect I am missing something simple - is there an option to, say, move the whole molecule or a zone that spans multiple chains? I would use Rotate/Translate - By Molecule... (the arrow is a toolbar togglebutton menu extension) Does that help? Regards, Paul. -- After much deep and profound brain things inside my head, I have decided to thank you for bringing peace to our home. Julian, King of Lemurs
Re: [COOT] saving an MTZ file after refinement
On Fri, 2012-06-15 at 17:51 +0100, Dan Scott wrote: Thanks to anyone who can answer my question :) That is tricky because your questions are confusing. I am not aware of any version of refmac that would not accept HKLOUT keyword. Then you ask how to save MTZ file while in coot, which makes even less sense. Unless you are running refmac from inside coot using the Azerbaijan flag button - in which case the hklout is stored in coot-refmac subfolder. -- I'd jump in myself, if I weren't so good at whistling. Julian, King of Lemurs
Re: [COOT] partial double conformers
Tim, On Thu, 2012-06-07 at 09:18 +0200, Tim Gruene wrote: - in general, rather than your specific case, I consider it bad practice to not split the full side chain but restrict the multiple conformation to a single atom. Maybe this is the reason coot does not offer this option. I agree. While I have no evidence to support this, I have the same feeling that sometimes the alternate conformer cannot quite comply with the density unless the backbone is allowed to split too. One way to deal with this would be to verify at the very end of the refinement if some alternate atoms are placed close enough so that a single conformation will suffice, but the question is what distance cutoff to use. You can still do it with a single line edit of the PDB file and adding 'A' to the first CE. Absolutely. You just exposed how much we all have been spoiled by coot (sam-atom-in, anyone?) :) Cheers, Ed. -- Coot verendus est
[COOT] partial double conformers
Are there plans to implement a partial double conformer feature? What I mean by this is that currently one can only choose whether to make alternate conformers with or without backbone atoms. I am staring at a methionine which only appears to have CE in different position, so it does not seem reasonable to have alternate positions for every other side chain atom. The workaround is to create double conformer for the whole side chain and then delete individual atoms - 4 clicks in this case, quite doable. But I thought maybe there is some trimming option or ideally one would be asked at which atom to split the chain. Cheers, Ed. -- Coot verendus est
Re: [COOT] partial double conformers
Tim, that is of course different from my original question, which was more about coot capabilities. It's ~1.7A, and I am not sure what you mean by model bias. To be more specific, there is a positive density peak suggesting alternative position for CE. When refined with full set of atoms, everything but CE ends up pretty much in the same place. I am sure terminal torsion angle affects positioning of atoms that are closer to the backbone, but the differences might be below the margin of error and there is simply no evidence for multiple positions of these. If you check, for instance, standard conformers 2, 3 and 4 for methinonine in coot, they are pretty much the same except for CE. It seems reasonable that only CE should be modeled in alternative positions. Cheers, Ed On Wed, 2012-06-06 at 23:23 +0200, Tim Gruene wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Ed, what resolution do your data have which make you think that the map you are staring at is without model bias? It is worth splitting the whole side chain for dual conformations and unlikely that really only one single atom as two possible conformations. Regards, Tim On 06/06/2012 09:16 PM, Ed Pozharski wrote: Are there plans to implement a partial double conformer feature? What I mean by this is that currently one can only choose whether to make alternate conformers with or without backbone atoms. I am staring at a methionine which only appears to have CE in different position, so it does not seem reasonable to have alternate positions for every other side chain atom. The workaround is to create double conformer for the whole side chain and then delete individual atoms - 4 clicks in this case, quite doable. But I thought maybe there is some trimming option or ideally one would be asked at which atom to split the chain. Cheers, Ed. - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFPz8o+UxlJ7aRr7hoRAsHeAKCp8ZQXkFXh5Zy8GrhxwI540O+NrACgudyZ /GRSaxHHcba2IzrtDERkopk= =7k3o -END PGP SIGNATURE-
Re: [COOT] reset occupancies for alt-confs
On Wed, 2012-05-09 at 17:06 +0100, Paul Emsley wrote: On 09/05/12 15:33, Ed Pozharski wrote: Is there a quick way to reset all the alt-conf occupancies in a residue? (zero-occupancy-residue-range imol chain-id resno-start resno-end) But this resets everything to *zero* occupancy, right? What I am looking for is to reset, say all the atoms of alt-conf A to 0.7 and those of alt-conf B to 0.3 for a particular residue. This would be useful if one splits a residue only to find that the B-factors for alt-conf B are significantly higher than those of A. A remedy then is to set uneven occupancies (assuming that one is not a big fan of occupancy *refinement*). Right now the only way I see in coot is to use Residue Info dialog, and as I said, that takes many keystrokes. Perhaps Residue info dialog could have apply to conformation A option similar to apply to all? Cheers, Ed. -- Coot verendus est
Re: [COOT] show valence for ligand and add hydrogens to just ligand ? Keep hydrogens during refmac run?
On Tue, 2012-04-17 at 11:54 -0400, hari jayaram wrote: Currently refmac removes the hydrogens during refinement and this may be some preference that I toggled and dont remember doing so. You mean it removes hydrogens even if you use MAKE HOUT Y? -- Coot verendus est
Re: [COOT] show valence for ligand and add hydrogens to just ligand ? Keep hydrogens during refmac run?
You can pass extra parameters to the refmac run by placing the instructions into the file named refmac-extra-params.txt. So just put MAKE HOUT Y there and see if the hydrogens are preserved. In my case Refmac run from inside coot does not preserve hydrogens if present , such as the ones that prodrg puts in .., I will try using modern refmac as Paul recommended... -- Coot verendus est
Re: [COOT] Inserting residues and backbones
And the resolution of your data is... ? On Mon, 2012-03-26 at 19:58 +0100, Alok Shenoy wrote: Hello, I'm working on a structure using coot, and I have a peculiar problem. Searching www didn't quite provide me with an answer, hence requesting more knowledgeable users for some help. Background: The structure has 2 chains, Chain A and Chain B. Chain B has all the residues that should be present according to our sequence, and the numbering on both chains are complete. Problem: 1) Chain A has a couple of residues missing. The numbering shows 231 232 234. Clearly marking out the spot where the residue is missing. Sequence shows that there is an aspartic acid missing in position 233. Problem is - both 232 and 234 are connected quite normally, inserting a terminal residue at 232 (alanine at first) results in absolutely weird connections. Deleting specific atoms in the backbone on the protein at that position (between 232 and 234) don't quite help either - as that results in 234 missing a peptide bond. 2) At some points, there is no backbone -by which I mean - lets say residue 100 and 101 side chains are showing up (and have appropriate electron density). What is missing is the peptide bond that connects these two residues (again - electron density for the backbone is present). Is there a way to fix this? Can someone walk me through the solution to this problems? Thank You, Alok Shenoy -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
Re: [COOT] Ubuntu Maverick and coot menus
Nat, On Sat, 2012-02-11 at 11:15 -0800, Nat Echols wrote: I think it's awful - after about 10 minutes I switched back to the old gnome UI. It seems that most people who used Ubuntu with gnome desktop for years dislike the Unity (myself included on both counts). Not so much the new users, who need to learn new trick anyway. I still don't understand what exactly they changed or what the advantage is supposed to be*, but for someone who's actually comfortable with Linux already it is a huge step backwards in functionality and makes the OS more difficult to use. It is quite obvious to me that Unity is an attempt to position Ubuntu for the tablet/smartphone market. Of course, this is not likely to be a good fit for a dual monitor crystallography workstation. To be fair, Ubuntu is owned by Canonical, and Shuttleworth can do whatever he wants with it, while individual users seem to be provided with gnome-session-fallback package. I was under impression that certain elements of Unity desktop make it look more like OSX. Given the axiom that OSX is the best desktop in the universe, how could that be a bad thing? ;-) If this is a reliable indication of where Ubuntu is going in the future, I need to find a new favorite distribution. Or reconfigure Ubuntu to fit your needs. That is what's great about Linux - you are not really locked into the vendor's solution. Cheers, Ed. -- Hurry up before we all come back to our senses! Julian, King of Lemurs
Re: [COOT] Coot - 3D Anaglyph
In theory (i.e. I have not tried this myself), if you can output a stereo pair of images from coot (or any other source), you can use a gimp plugin to make anaglyph images http://registry.gimp.org/node/6527 Ed. On Thu, 2012-01-26 at 12:06 -0800, William G. Scott wrote: Does coot do red/greed (anaglyph) stereo? All google showed me was this: http://www.flickr.com/photos/hindt3d/2268014240/ This would be useful for classroom settings. -- Bill William G. Scott Professor Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA 228 Sinsheimer Laboratories University of California at Santa Cruz Santa Cruz, California 95064 USA phone: +1-831-459-5367 (office) +1-831-459-5292 (lab) fax:+1-831-4593139 (fax) email: wgsc...@ucsc.edu -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
Re: [COOT] New restraints, same name
On Tue, 2012-01-24 at 15:26 -0500, Kendall Nettles wrote: That didn't come out right. What I meant to say was that he are often comparing structures from a series of closely related compounds. But isn't it true that non-identical compounds should have different names? Paul also refers to refinement (i.e. when dictionary is needed), not comparison (the latter should be fine with identical names). Cheers, Ed. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
[COOT] map-molecule-chooser-gui
The first time you call any command that need a target map to be defined (e.g. real space refinement), the map chooser gui comes up. But then the command that initiated it does not really get executed, and you have to call it up again. Now, this is just a minor nuisance as it only happens once per session. But I wonder, is there something that fundamentally prevents the initial command from being executed? Alternatively, is it possible to make sure that whenever the first map is loaded it becomes the target for refinement? Cheers, Ed. -- Coot verendus est
Re: [COOT] ANISOU error
I tracked this error down to mmdb library, and it has nothing to do with ANISOU records per se (it is indeed highly unlikely that anyone would implement a rigorous check of matching Uij's to Bs). Apparently, mmdb expects the element field (77-78 in both ATOM/ANISOU records) to be filled. My expectation was that if the field is empty it will be ignored or constructed from the atom name, but apparently it's not so. This is obviously not related to coot and in most scenarios the problem can be alleviated by, say, passing a file through pdbset... Take that back, pdbset fails too as it apparently is using mmdb. Well, maybe 0 cycles of refmac will produce a readable file. Or maybe there is some other pdb-fixing tool. It also appears that mmdb will by default pay attention to the segment ID, which it reads in positions 71-74 or such. This is not defined in official PDB format, but mercifully mmdb will only fail if you have a mismatch - empty segid will be ignored. Cheers, Ed. On Mon, 2011-10-24 at 15:27 -0400, Ed Pozharski wrote: I get an error when trying to load a file that contains ANISOU records. ... ERROR 14 READ: Unmatch in different records for the same atom. LINE #2 ANISOU1 N ASN A 60 8621383 2100134 -2339 351 ... I suspect that it fails because the Uij's from the ANISOU record do not match the B-factor listed on the ATOM line, e.g. ATOM 1 N ASN A 60 23.118 41.711 36.893 1.00 93.11 ANISOU1 N ASN A 60 8621383 2100134 -2339 351 The question is, why should it fail in this situation? The only way I see the ANISOU records are used is to show the thermal ellipsoids, and the mismatches may occur in some other benign situations (e.g. someone resetting the B-values manually). Or is it a bug? In a particular application I am dealing with the mismatch is deliberate and the ANISOU records are used exclusively for visualization purposes. This worked in the past. Ed. -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
Re: [COOT] Installing Coot onto Ubantu
On Mon, 2011-09-19 at 13:16 -0400, Young-Jin Cho wrote: When I typed coot, the following error message showed up: It's 64-bit OS you are using, right? CCP4/coot you downloaded is 32-bit, and thus is out of luck with shared libs. You can try installing ia32 libs, but it probably won't work either. Your options are: The worst: cahse down dependency and install the corresponding 32-bit libs in /usr/lib32 or such Worse: reinstall the 32-bit OS Better: download the right version directly from coot website Better yet: Install coot using Morten Kjeldgaard's PPA http://strucbio.biologie.uni-konstanz.de/ccp4wiki/index.php/Coot#Packages_for_Ubuntu The best: compile the latest coot yourself http://biop.ox.ac.uk/coot/build-install-coot-from-scratch.html The last option - totally worth it. Then you can ask yourself: Who is Lidia? :) -- Coot verendus est
[COOT] refine/improve Rama
Is there some way to do the Refine/Improve Ramachandran plot not on the whole molecule? The underlying command stepped-refine-protein-for-rama doesn't seem to have any other options but the imol, so obviously no luck. I also tried set-refine-ramachandran-angles 1 which, afaiu, should turn Ramachandran restraints on, but I don't see any difference (in fact, when I refine a zone the residues move away from allowed angles). I thought that this could be combined with stepped-refine-protein, but that one would also tackle the whole thing, and one cannot narrow its action to a zone. I could, of course, delete the elements I don't want refined and later reinsert them. Another workaround (maybe) is to fix the atoms I don't want to move (in which case it'd be totally awesome if one could fix all the atoms in a zone at once - is this possible?). So, perhaps a future version may allow for all of these operations (e.g fit-protein, stepped-refine-protein, stepped-refine-protein-for-rama) tp be applied to a zone? Please? Cheers, Ed. PS. Well, I was told long time ago that restraining Ramachandran angles is a BAD idea because they should only be used for validation. But this is 3A data. -- Coot verendus est
Re: [COOT] Nomenclature errors
Google is your friend: http://www.biop.ox.ac.uk/coot/doc/coot/Fix-Nomenclature-Errors.html Yes, that dialog freaked me out at first too, but from what I understand it just fixes ambiguities (e.g Phe/Tyr flips and such). On Thu, 2011-09-15 at 09:47 -0700, Engin Özkan wrote: Dear coot users and developers, We are using coot 0.7-pre-1 (rev 3633) in the lab on linux and Mac machines, and have observed something odd that we did not see before. Most (all?) pdb files when opened give a (harmless) warning that says Molecule x has nomenclature errors. Correct them? The residues mentioned are Phe's, Tyr's, and Asp's. I don't think there was an update to these residues in the latest dictionary. Before I go into more detail, is anybody else seeing this, and should we just install a newer nightly? I should note that these models have been refined by Phenix versions 1.6 and 1.7, and molprobity thinks they are perfectly fine. There are no DNA/RNA bases, and odd ligands, except sugars in them. Best, Engin -- Coot verendus est
Re: [COOT] Clear on screen labels?
but how do I remove all the labels at once? Measures-Distances and Angles-Clear all atom labels -- Coot verendus est
[COOT] ubuntu coot fails on monomer search
First of all, let me say that having coot packaged for Ubuntu is fantastic. Not only it makes it easier to install, to me another important consequence is the the Linux small-size promise is thus fulfilled. However, I ran into some trouble with ligand incorporation. Specifically, malonate ion. Scenario 1. CCP4 is not configured. Nothing works. If I try to search for either 3-letter code or by keyword I am told that CCP4_BIN is not set etc., it offers to search entire disk for libcheck, which takes so long I canceled it. Attempted workaround: I put symbolic link to libcheck into /usr/local/bin or define libcheck alias. Still doesn't work - the relevant line in coot terminal may be #ERROR: cant open (lib) list/mon_lib_list Setting CCP4_LIB to point at /usr/share/refmac doesn't help. Scenario 2. CCP4 is configured (6.1.13). You can find malonate through coot menu, but libcheck fails with a different message # WARNING : monomer:MLI - not found in the library . This seems to suggest that libcheck is looking in CCP4_LIB and the monomer library that comes with 6.1.13 has no malonate. If I choose methyl-malonic acid (DXX) it works fine because DXX is in 6.1.13 monomer library. So it seems that the problem is that Ubuntu Coot looks for monomers in /usr/share/refmac but then invokes libcheck which looks elsewhere. BTW, copying MLI.cif to $CCP4_LIB/data/monomers/m doesn't help, perhaps because libcheck relies in mon_lib.list or such. I can probably figure out which files to amend to include MLI, or maybe an update is available for the latest refmac monomer libs, but this would still be an ugly workaround. I think ideal solution would be to have refmac monomer libs adopted as a separate package by CCP4, but I doubt that CCP4 is interested in maintaining packages for various linux distros. I can understand why CCP4 doesn't go the Linux way with dependencies - their goal is to assure successful installation, not to maximize library sharing. Alternatively, Ubuntu Coot could depend on a separate libcheck package - but unless I missed something, it doesn't do that now. Is this thus a bug and what could be a workaround? The only one I know is to import cif-file and ligand pdb manually, which works but makes get-monomer less useful. Cheers, Ed. -- Coot verendus est
[COOT] feature suggestion
Could it be interesting to add the feature of downloading a model/density from PDB_REDO server in addition to the EDS? Presumably, these can be sometimes better quality maps (having no specific evidence for this, I nevertheless expect it given systematically lower Rfree for the re-refined models). -- Coot verendus est
Re: [COOT] Fwd: exploding hydrogens during real space refinement in coot
On Wed, 2011-03-02 at 14:27 +, Paul Emsley wrote: Given that PRODRG is popular (well, I imagine so), and so are hydrogens (they should be, at least) and maybe Coot also, I would have expected to see complaints about this every week! PRODRG is quite awesome and mine (and presumably everybody's) feelings about coot are pretty much summarized by the Latin inscription on the bottom. So it must be the hydrogens. Must confess I have never used them explicitly - time to grow up :) -- Coot verendus est
Re: [COOT] Red Hat Enterprise Linux 6 (RHEL 6) compability issue
On Wed, 2011-03-02 at 11:37 -0500, Ben Eisenbraun wrote: Couldn't Coot just use the binary that came with the operating system? No. The library is the proper thing to use. Also, wget depends on libssl anyway, so using it via, say, popen call would simply add an extra unnecessary dependency. Not that there is anything fundamentally wrong with this (unless one is a purist) - I'd say when one needs to get a crude but working code quickly set up in a specific environment abstraction of this kind saves time and the modern cpu power reduces the speed penalty to undetectable levels. Still, Ben is correct and using a library (which is binary too) is more appropriate. -- Coot verendus est
Re: [COOT] save symmetry coordinates
Don't know if such feature already exists in coot, but there are many possible ways to script this using some other software. First thing that comes to my mind is CNS - it has the neighborhood.inp script to do this. The next easiest thing is probably doing it in pymol, which already has a shortcut to generate all the symmetry mates within certain distance. Something as simple as save command with a wildcard could do it. On Wed, 2011-02-23 at 17:36 +0100, cedric bauvois wrote: Sorry, I mean to say save all of them in one single step ? (for example using a cutoff distance of 10 A) 2011/2/23 Ed Pozharski epozh...@umaryland.edu On Wed, 2011-02-23 at 16:40 +0100, cedric bauvois wrote: Dear all, Is there a way to save all symmetry related coordinates which are close to the ones given in the input file ? Thanks ! Cedric While the answer is trivial and has been given many times before (just look at File-Save symmetry coordinates and then click on the copy you want to save), I must admit that I can't quite find where the gui route of doing this is described in the manual (the save-symmetry-coords command is there). Ed. -- Coot verendus est -- .. Dr. Cedric Bauvois Cristallographie des protéines Institut de Recherches Microbiologiques J.-M. Wiame -IRMW Campus CERIA - Av. E. Gryson, 1 B-1070 Bruxelles, BELGIUM e-mail: cedric.bauv...@ulb.ac.be tél: +32 (0)2 5273634 fax: +32 (0)2 5267273 .. -- Coot verendus est
[COOT] bug
First and foremost, the screenshot feature that interfaces with Raster3D is awesome. I noticed, however, that it does not warn me of overwriting existing files (I didn't screw anything up yet, but the danger is there when one adjusts the molecule for a better screenshot and writes over previously saved png). Using Miramar-3039. Ed. -- Coot verendus est
Re: [COOT] Colour by chain
On Tue, 2010-11-16 at 13:22 +, Paul Emsley wrote: also is there any way of refining a zone around a metal ion without the sidechains vanishing into the metal density? I know the refine-by-sphere (R) option works better, but then I have no control over what I'm refining Had the same problem when using the marvelous Refine/Improve Ramachandran plot function - does a great job, but sometimes pushes sidechains into the metal ion density. A workaround is to exclude metals from the map by Mask map by atom selection. HTH, Ed. -- Coot verendus est
Re: [COOT] adding residues (feature request?)
On Tue, 2010-11-16 at 13:34 +, Paul Emsley wrote: (set-default-temperature-factor-for-new-atoms 50) But perhaps that is what you mean by resetting the defaults. Precisely. I think it makes perfect sense if coot assigns B-factors to new residues by extrapolating from existing ones, but again, this is a minor issue that is easy to deal with otherwise. Thanks. -- Coot verendus est
Re: [COOT] create map around select residues
Extensions-Maps-Mask map by atom selection http://www.biop.ox.ac.uk/coot/doc/coot.html#masks On Wed, 2010-11-03 at 16:00 -0700, jy wrote: Hi All, I am new to the list and coot. I am wondering how to create a map that only show selected residues? so the surrounding background is not showing. thanks a lot! jie -- Coot verendus est
Re: [COOT] adding residues (feature request?)
Bernhard, I think for the loop that is about to close taking the average from flanking residues is good enough. Not sure what you mean by the second example (last residue has a low B). I think what causes problems in refmac is a sharp discontinuity, as it contributes greatly to the B-factor restraints. Refinement will adjust B-factors properly if they are higher/lower, but not if they jump from 90 to 20 from residue to residue. The way I adjust B manually is by looking at the B-factor of the next residue, which is not too sophisticated approach and should be easy to implement. Well, in the end it's a minor problem, and easy to fix manually. Cheers, Ed. On Thu, 2010-11-04 at 16:11 +0100, Bernhard Lohkamp wrote: Dear Ed, I think I get your idea, however this is not a straight forward issue I believe. What do you imagine happens for a loop then? You may end up connecting a high B residue to a low one when closing it? Does that make refmac happy? Or your last residue (since it is still well ordered) has a low B, then you dont gain anything? More appropriate may be a weighting and adjustment of B-factors based on e.g. real-space CC. But I guess until we have tools in Coot to refine (or in the first instance guess) B-factors you better adjust the Bs yourself. Your guess (knowing the structure and seeing the map) is better than any approximation we can easily come up with (at least for now). My 50 Oere (just fazed out BTW), Bernhard When adding residues to the N- or C-terminus, it may be desirable that the B-factors of the new residue match that of the previous terminal residue. Right now it uses defaults (20 for main chain, 30 for side chain) which are sensible fir a well-ordered model, but this causes problems with the subsequent refmac run for somewhat disordered regions whereB may be significantly higher. The current workaround is to modify residue properties manually (or keep resetting the defaults). Naturally, the wisdom of adding extra residues withB~100 is questionable :) Cheers, Ed. -- Coot verendus est
Re: [COOT] NAD not possible to do real space refinement and rebuilding in coot
Maria, try the attached files - I got them from Garib awhile ago when I experienced similar naming problems (although in my case NAD was refined, but to the effect of severely distorted geometry). Good luck, Ed. On Tue, 2010-10-26 at 15:08 +0200, Maria Hakansson wrote: Dear Paul, I have a rebuilding problem of a NAD molecule using coot. The NAD molecule was fetched using the load monomer command in coot and the restraints cif file was also in the library. However the program complains about Fails to match model atom names NN7 and NN1 and thus it is not possible to do real space refinement. I guess it is a naming issue. Any advice how to get around it? The coordinates are possible to refine using Refmac so it seems to be more coot related than general. Best regards, Maria _ Maria Håkansson, Ph.D. Phone: +46 (0) 76 8585 706 Fax: +46 (0) 46 19 12 77 Senior Scientist, SARomics Biostructures AB Scheelevägen 22 (P.O. Box 724) SE-220 07 Lund, Sweden Web address: www.saromics.com Email: maria.hakans...@saromics.com ___ -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse / global_ _lib_name mon_lib _lib_version 4.12 _lib_update 20/09/07 # # # --- LIST OF MONOMERS --- # 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 NAD . '. ' non-polymer70 44 . # # --- DESCRIPTION OF MONOMERS --- # data_comp_NAD # loop_ _chem_comp_atom.comp_id _chem_comp_atom.atom_id _chem_comp_atom.type_symbol _chem_comp_atom.type_energy _chem_comp_atom.partial_charge _chem_comp_atom.x _chem_comp_atom.y _chem_comp_atom.z NAD O7NOO 0.000 0.028 -0.024 -0.001 NAD C7NCC 0.000 -0.365 -0.929 -0.723 NAD N7NNNH2 0.000 0.450 -1.947 -0.951 NAD HN72 HH 0.000 1.367 -1.959 -0.532 NAD HN71 HH 0.000 0.151 -2.707 -1.543 NAD C3NCCR6 0.000 -1.720 -0.887 -1.317 NAD C2NCCR16 0.000 -2.5540.197 -1.063 NAD H2NHH 0.000 -2.2101.005 -0.429 NAD C4NCCR16 0.000 -2.177 -1.902 -2.132 NAD H4NHH 0.000 -1.549 -2.755 -2.354 NAD C5NCCR16 0.000 -3.447 -1.810 -2.657 NAD H5NHH 0.000 -3.819 -2.600 -3.299 NAD C6NCCR16 0.000 -4.249 -0.729 -2.378 NAD H6NHH 0.000 -5.250 -0.672 -2.787 NAD N1NNNR6 1.000 -3.7860.245 -1.600 NAD C1DCCH1 0.000 -4.6381.391 -1.342 NAD H1DHH 0.000 -4.2641.900 -0.443 NAD O4DOO20.000 -6.0141.028 -1.111 NAD C2DCCH1 0.000 -4.6562.421 -2.507 NAD H2DHH 0.000 -4.3911.919 -3.448 NAD O2DOOH1 0.000 -3.7503.505 -2.264 NAD HO2D HH 0.000 -3.7254.084 -3.039 NAD C3DCCH1 0.000 -6.1192.933 -2.581 NAD H3DHH 0.000 -6.5732.668 -3.546 NAD O3DOOH1 0.000 -6.1894.348 -2.362 NAD HO3D HH 0.000 -7.0984.650 -2.491 NAD C4DCCH1 0.000 -6.8172.184 -1.429 NAD H4DHH 0.000 -6.8332.844 -0.550 NAD C5DCCH2 0.000 -8.2241.758 -1.719 NAD H5D1 HH 0.000 -8.2111.049 -2.550 NAD H5D2 HH 0.000 -8.8052.638 -2.003 NAD O5DOO20.000 -8.8221.137 -0.565 NAD PN PP 0.000-10.3410.783 -0.932 NAD O1NOOP0.000-11.1392.062 -1.118 NAD O2NOOP -1.000-10.304 -0.153 -2.137 NAD O3 OO20.000-11.057 -0.0540.251 NAD PA PP 0.000-12.274 -0.832 -0.475 NAD O1A
Re: [COOT] Can I superimpose maps of two different structures?
Extensions-Maps...-Transform maps by LSQ model fit is likely what you are looking for. Also, googling coot superimpose maps quickly points here http://www.mail-archive.com/ccp...@jiscmail.ac.uk/msg05093.html On Tue, 2010-10-05 at 19:57 +0100, Subhangi Ghosh wrote: Hi all, I'm using coot version 0.6.2-pre-1. Is there anyway that after superimposing two structures, I can also superimpose their respective maps? Thanks very much, Subhangi -- Coot verendus est
Re: [COOT] preferences ignored when loading pdb/mtz from command line
Thanks, Bernhard. This may lead to another somewhat undesirable behavior - say I invoke a script that sets some parameters using --script option. If the script is processed *prior* to reading the current configuration from $HOME/.coot-preferences folder, then all the changes will be reset... Wait a minute, it seems that my premise is wrong and --script is processed *after* the configuration is loaded, since the attached script works exactly as I intended - loads the latest pdb/mtz files from the current folder and the sampling rate is right, at 2.5. Cheers, Ed. On Sun, 2010-10-03 at 13:54 +0200, Bernhard Lohkamp wrote: Ed, Currently command line data are handled in Coot before any scripting information (e.g. preferences) is processed. Hence the default map sampling is valid for the command line map but the preference set one for subsequently opened maps. I guess we may want to revisit the command line arguments and consider processing some (all?) after the scripting (i.e. preferences) is dealt with. B I think the preferences are ignored when I use coot --auto mymap.mtz or such to load the map from command line. I noticed because I always set map sampling rate to 2.5, and when --auto option is used from command line, I am positive maps are rendered with the default value of 1.5. Curiously, after quitting coot and restarting it and picking the last state, it's the same map but this time sampled at 2.5. This is exactly the reason I don't use the View result of refinement in Coot button in ccp4i - it ignores whatever preferences I have set previously. So I used to simply open coot and load the latest pdb/mtz from the current folder manually, but then I thought myself smarter than that and wrote a little script that picks the latest pdb/mtz from the current folder and opens them in coot. To my dismay, the preferences are ignored and I end up using the script but then going through quit/restart routine - works, but not perfect. I can think of couple of more elegant workarounds, but the question remains - why coot local ignores preferences whenever you supply options in a command line? Bug or feature? Cheers, Ed. cootlast Description: application/shellscript
[COOT] alternate conformers and ramachandran map
Are alternate conformers supposed to show up in Ramachandran map? I have a disordered loop which I modeled in two conformations and number of outliers reported magically goes down. After clicking few times on residues in the loop coot crashes but only when mouse pointer is moved over to the map dialog. It reports segmentation fault and I can generate crash dumps if necessary. I am running 0.6.2. revision 3011. Also, in this revision there is a problem with sequence dialog - the first ten residues are shifted out of the dialog on the left side. Ed. -- Coot verendus est
Re: [COOT] atoms used for SSM rmsd
Per SUPERPOSE manual, they are. I believe the distances for individual residues are for Ca atoms too. On Fri, 2010-07-02 at 14:17 +0200, Tim Gruene wrote: Dear all, which atoms are used for the calculation of an SSM superposition in coot? I suppose they are only the C-alpha atoms but would like to have a confirmation. Ta, Tim -- Coot verendus est
Re: [COOT] Too maye open files
Paul is right, this ain't coot problem. Some other application may be failing to close all the files it opens. It's PulseAudio, which I can attest was notoriously unstable under some Linux flavors. You can try killing it (pulseaudio -k), that what I used to do all the time (I didn't have your bug, but rhythmbox just wouldn't play anything until I did). This may also be hardware specific. Take a look at this https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good0.10/+bug/298820 Your best solution may be to upgrade whatever Linux flavor you are running, as this is probably solved in the latest version of gst-plugins-good or whatever is not closing the sound pipes. HTH, Ed. On Wed, 2010-06-16 at 09:57 +0100, Guillermo Carrasco wrote: Hi, I'm the system manager of a network in which we are using coot. A few days ago a user sent me a message telling that when he has been working with coot for about 3-4 hours, he get an error message like this: E: client-conf-x11.c: XOpenDisplay() failed W: core-util.c: Failed to open configuration file '/users/USERNAME/.pulse/client.conf': Too many open files W: client-conf.c: Failed to open configuration file '/etc/pulse/client.conf': Too many open files W: shm.c: Failed to read /dev/shm/: Too many open files I don't know what's happening, can anyone help me please? Thank you very much. -- Coot verendus est
[COOT] how to invoke atom picking
On Wed, 2010-06-09 at 16:44 +0100, Judit Debreczeni wrote: Not sure what you'd like to achieve, but perhaps the map_molecule_chooser_gui is what you are looking for. Thanks - exactly what I was looking for (and molecule_chooser_gui too!). Is there some to invoke an atom-picking event from python script? Something that would ask for user to click on some atom and then either return the atom id or call a function. Or just wait until atom is clicked and then proceed, since one can always get the current selection via active_residue(). There is residue_range_gui, but it's (probably) just to show a range selector dialog. All I found in the manual is clear_pending_picks(), but what I want is the opposite. Cheers, Ed. -- Coot verendus est
Re: [COOT] Save Coordinates (as) ...
I think a preference setting that specifies if you do or do not add -coot-# to the file name is the best solution. Or even better - let user define the format (with original_name-coot-%d.pdb % next_version as default). Theoretically coot now does it in the safest way, as you are not at risk of overwriting something without being explicitly warned. I too hate when folder listings become unmanageable because of all the crumbs - maybe there could be a cleanup option of deleting everything but the latest copies of everything. Cheers, Ed. On Fri, 2010-06-11 at 16:14 +0200, Miguel Ortiz Lombardia wrote: I've been a fan of this idea since coot 0.0.33 or so :-) Great to see others think it would be useful. Another possibility would be a preference setting to always make a backup of the original coordinates file. Kind of what emacs does. Best, Miguel Le 9 juin 2010 à 11:47, Tim Gruene a écrit : Grand idea, I support it! On Wed, Jun 09, 2010 at 11:07:16AM +0200, Dirk Kostrewa wrote: Dear Paul, another point for your wish list: usually, I save coordinates quite frequently during a model building session, giving always the same name for that session like myproject-coot6.pdb. Coot always asks me to select a file name and appends -coot-0 before the .pdb, which I find quite tedious. My suggestion is: offer both a Save Coordinates, with only an initial query for the output file name, and a Save Coordinates as ... option. That would offer the user to either quickly overwrite the initial output file or save the coordinates to a new output file name. Best regards, Dirk. -- *** Dirk Kostrewa Gene Center Munich, A5.07 Department of Biochemistry Ludwig-Maximilians-Universität München Feodor-Lynen-Str. 25 D-81377 Munich Germany Phone: +49-89-2180-76845 Fax: +49-89-2180-76999 E-mail:kostr...@genzentrum.lmu.de WWW: www.genzentrum.lmu.de *** -- -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen GPG Key ID = A46BEE1A -- Miguel Architecture et Fonction des Macromolécules Biologiques (UMR6098) CNRS, Universités d'Aix-Marseille I II Case 932, 163 Avenue de Luminy, 13288 Marseille cedex 9, France Tel: +33(0) 491 82 55 93 Fax: +33(0) 491 26 67 20 e-mail: miguel.ortiz-lombar...@afmb.univ-mrs.fr -- Coot verendus est
[COOT] show_select_map_dialog
(Python scripting option verendus est) In python script, it appears that show_select_map_dialog simply shows the dialog and quits. I am trying to set up a method that would do certain things depending on the choice of map. So I use show_select_map_dialog, but it appears that it does not wait until user makes a choice there. I tried to put a sleep cycle for 10 seconds that would keep checking if map selection changed, but the dialog does not show until the cycle is over. Is there any way to show the dialog and then wait for user to make selection? Here is the version of the code that shows the dialog but then proceeds further without waiting for selection --- show_select_map_dialog() imodel = (imol_refinement_map() - shknum)/2 highlight_model(imodel) --- Her is the code with sleep-cycle. This one only shows the map selection dialog after 10 seconds (something equivalent to yield function in wx is needed) --- from time import sleep imap = imol_refinement_map() show_select_map_dialog() for i in range(10): if imap != imol_refinement_map(): break sleep(1) imodel = (imol_refinement_map() - shknum)/2 highlight_model(imodel) --- -- Coot verendus est
Re: [COOT] auto-save upon exit
Awesome, thanks (is this in some manual somewhere?). But I am looking for the way to do this automatically - e.g. a script that gets executed prior to exiting. For instance, coot does warn that you modified but didn't save your model(s), so is there some way to make it do the (quick-save) at this point instead? Ed. On Tue, 2010-06-08 at 10:56 +0200, Bernhard Lohkamp wrote: Try: pythonic: quick_save() scheme: (quick-save) This will save all pdb files with unsaved changes (using default naming). B Is there an elegant way to make coot save modified pdb-files automatically upon exiting? Just saving all the pdb files will work for me too. I am calling coot from a python script so I can in principle scan the coot-backup folder after session has closed and grab latest files from there, but maybe there is some python scripting solution? I did try to rtdm, but may have missed something. Ed. -- Coot verendus est
[COOT] make-and-draw-map fails to read a difference map
This command (make-and-draw-map ../refined01.mtz DELFWT PHDELFWT 0 1) fails to make the difference map. Coot appears to report that the mtz-file (produced by refmac) does not have the DELFWT/PHDELFWT columns, which it does. The 2fo-fc map works just fine. Moreover, I can import the difference map from the gui and the columns in question are found. Coot reports the following valid_labels(../refined01.mtz,DELFWT,PHDELFWT,,0) returns 0 WARNING:: label(s) not found in mtz file ../refined01.mtz DELFWT PHDELFWT I noticed that gui uses make-and-draw-map-with-reso-with-refmac-params and calls the columns /unknown/unknown030610/DELFWT and /unknown/unknown030610/PHDELWT, which must be the CRYSTAL, DATASET records from the mtz file. I want to load several maps from a script knowing nothing but file names and column names, so what am I doing wrong? Ed. PS. I just found the solution for refmac output, which is auto-read-make-and-draw-maps. Works fine and I don't need to specify column names. Still, shouldn't make-and-draw-map work too? -- Coot verendus est
Re: [COOT] make-and-draw-map fails to read a difference map
Yes indeed. It's time for eye exam, Ed. On Fri, 2010-06-04 at 18:53 +0200, Tim Gruene wrote: Dear Ed, is it on purpose that you typed PHDELFWT ^ whereas coot seems to read PHDELWT ? If this is an unintentional difference, it might also be the solution to your problem. Tim On Fri, Jun 04, 2010 at 12:16:27PM -0400, Ed Pozharski wrote: This command (make-and-draw-map ../refined01.mtz DELFWT PHDELFWT 0 1) fails to make the difference map. Coot appears to report that the mtz-file (produced by refmac) does not have the DELFWT/PHDELFWT columns, which it does. The 2fo-fc map works just fine. Moreover, I can import the difference map from the gui and the columns in question are found. Coot reports the following valid_labels(../refined01.mtz,DELFWT,PHDELFWT,,0) returns 0 WARNING:: label(s) not found in mtz file ../refined01.mtz DELFWT PHDELFWT I noticed that gui uses make-and-draw-map-with-reso-with-refmac-params and calls the columns /unknown/unknown030610/DELFWT and /unknown/unknown030610/PHDELWT, which must be the CRYSTAL, DATASET records from the mtz file. I want to load several maps from a script knowing nothing but file names and column names, so what am I doing wrong? Ed. PS. I just found the solution for refmac output, which is auto-read-make-and-draw-maps. Works fine and I don't need to specify column names. Still, shouldn't make-and-draw-map work too? -- Coot verendus est -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
[COOT] autobuilder bug (0.6.2 beta-tests)
Autobuilder fails in the latest 64-bit Ubuntu version (10.04 LTS Lucid
Lynx). The problem is related to gtkglext, which the last step
(building coot itself) fails to find despite being successfully
compiled.
The solution (found by Hari Jayaram) is to install gtkglext, e.g.
sudo apt-get install libgtkglext1
I don't know if other related libs I have in my system
(libgtkglext1-dev, libgtkglext1-dbg and python-gtkglext1) are
necessary.
Then you have to tell autobuilder script not to build gtkglext, which
can be accomplished by applying the attached patch to the
build-it-gtk2-simple downloaded by cootbuilder script. The modified
coorbuilder script is attached (make sure the patch is in the same
folder).
This does not actually fix the bug, since as I understand the purpose of
autobuilder is to minimize the number of pre-required dependencies.
--
Coot verendus est
387c387
check_dependencies_in_install_only=1
---
check_dependencies_in_install_only=0
1509c1509
build_gtkglext=
---
build_gtkglext=0
1883c1883
build_gtkglext=1
---
build_gtkglext=0
wget http://www.ysbl.york.ac.uk/~emsley/build-logs/build-it-gtk2-simple
patch build-it-gtk2-simple coot_autobuilder_ubuntu_10.4_gtkglext.patch
export AUTOBUILD_INSTALLED=${HOME}/sware/coot/autobuild/coot
export AUTOBUILD_BUILD=${HOME}/sware/coot/autobuild/
export LOGS=$AUTOBUILD_BUILD/logs
export NIGHTLY_DEST_DIR=$AUTOBUILD_BUILD
export STABLE_DEST_DIR=$AUTOBUILD_BUILD
export build_coot_prerelease=1
bash build-it-gtk2-simple python build.log
[COOT] 0.6.2. bug
I am not sure if it's a bug or a feature, but if I do SSM superposition and symmetry is turned on, then environmental distances *include* those to now incorrectly placed symmetry mates. It would seem logical if symmetry information would be lost upon transformation. Of course, this is easy (albeit tedious) to resolve manually by turning off symmetry for the transformed molecule. -- Coot verendus est
[COOT] 0.6.2 - environment distances bug
I have two molecules loaded. The environmental distances are turned on. Click on molecule 1, shows distances for molecule 1. Click on molecule 2, shows distances for molecule 2 - so far so good. Now with one molecule selected and showing distances, I hide other molecule in display manager. Dashed lines for distances disappear. If I hide the selected molecule instead, dashed lines stay. Experiment with 3 molecules loaded shows that bug seems to affect molecules that are next to each other in the list. For instance, if I select #1, then hiding #2 hides the dashed lines, but hiding #3 doesn't. The bug also shows some hysteresis - resetting show residue environment checkbox makes it behave normally, but only until different molecule is selected. -- Coot verendus est
Re: [COOT] beta testers for 0.6.2
Two questions: 1. This does not include autobuilder bugs, right? 2. What is the bug reporting procedure - just email the list? Ed. On Mon, 2010-05-10 at 16:17 +0100, Paul Emsley wrote: Hi Cooters, We are approaching the release of 0.6.2, which will be the last version using gtk1 and guile-gtk. I want to move on to concentrating on a project, rather than tweaking the 0.6.x series. So this is a call for beta testers to make sure that 0.6.2 is ship-shape (and I mean by that, that we need to find bugs, not missing features [1]). If you'd like to give it a go, please pick up the latest dev builds from here: http://www.biop.ox.ac.uk/coot/devel/build-info.html Thanks, Paul. [1] although of course sometimes that's a fine line. -- Coot verendus est
[COOT] command line and customized options (bug/feature?)
It appears that when loading model/map from command line (via --pdb and --auto options) coot ignores the parameters defined in $HOME/.coot . Mine has the (set-map-sampling-rate 2.5) setting for smoother maps, but when I use the command line to load pdb/mtz files, the maps look more like sampling rate 1.5 . Workaround is to open coot from command line, then close it, and then reopen it and accept the dialog that loads from last coot state file. Maps are smooth again. Of course, one can also load a script at the start that fixes the sampling rate. I am just saying that the expected behavior would be to import $HOME/.coot even if there are parameters in the command line. Or is it a feature? -- Coot verendus est
[COOT] sequence view
Would it be possible to reduce gaps in the sequence view window to, say, no more than five letters in those cases when residue numbers on the same chain jump up when going from protein to ligands/water? I understand on some level the rationale behind PDB standard of setting chain ID for heteroatoms to whatever protein chain they belong to (yet I miss the freedom of creating separate chains for ligands/waters and numbering them to my liking). The unfortunate consequence if this convention is that the residue list in the sequence view dialog becomes very long (and ligands are hard to distinguish from waters as they form long string of X's). -- Coot verendus est
Re: [COOT] americanisms in 0.6.1....
Felix, Notice that google translator also lists простак, глупец which, as you know, is probably best back-translated into English as fool. So I guess we can use this ambiguity to come up with a slogan for coot, something like it's so easy to use even a coot can do it :) As for Latin version, my coot-specific email signature says it all. Cheers, Ed. On Fri, 2010-01-29 at 10:23 +0200, Felix Frolow wrote: Latin : Fulica atra Russian: Лысуха Hebrew: אגמית -- Coot est verendus
Re: [COOT] Uniformly awful goodness?
Here is what coot manual says about this, The density fit graph shows the density fit for residues. The score is the average electron density level at the atom centres of the atoms in the residue. The height of the blocks is inversely proportional to the density average. The residue density fit is by default scaled to a map that is calculated on the absolute scale. Sometimes you might be using a map with density levels considerably different to this, which makes the residue density fit graph less useful. To correct for this you can use the scripting function: (set-residue-density-fit-scale-factor factor) where factor would be 1/(4\sigma_map) (as a rule of thumb). (residue-density-fit-scale-factor) returns the current scale factor (default 1.0). On Fri, 2010-01-29 at 10:09 -0800, Ethan Merritt wrote: I am wondering how the goodness scale for density fit analysis is determined. I have a case here where to the eye there is a very good fit of model to density throughout 99% of the unit cell, yet the validation tool marks most residues with a big red bar. Is there some hidden property [e.g. map gradient?] that triggers a bad validation score even though the fit to density looks fine by visual inspection at a single contour level? Is the good-to-bad scale normalized to the individual structure, so that a 'good everywhere' structure looks 'uniformly bad' in the validation tool? Would the presence of large difference peaks outside the area of the current model make any difference? -- Edwin Pozharski, PhD, Assistant Professor University of Maryland, Baltimore -- When the Way is forgotten duty and justice appear; Then knowledge and wisdom are born along with hypocrisy. When harmonious relationships dissolve then respect and devotion arise; When a nation falls to chaos then loyalty and patriotism are born. -- / Lao Tse /
[COOT] EDS retrieval
The latest Coot appears to fail (I have revision 2641 I built yesterday) on Karmic) to get the models/maps from EDS server. The appropriate files in the coot-download folder contain errors like these: The requested URL /eds/sfd/1ulr/pdb1ulr.ent was not found on this server. What I noticed is that the coordinate link at EDS website looks like this: http://eds.bmc.uu.se/eds/dfs/ul/1ulr/pdb1ulr.ent I don't know if something changed at Uppsala, but wget fails to retrieve, for instance, the example listed in scheme/get-ebi.scm http://eds.bmc.uu.se/eds/sfd/1cbs/pdb1cbs.ent I took liberty to learn a little scheme and edited couple of lines in the file and it seems to work now. I attach the patch-file (to apply it, do patch get-ebi.scm get_ebi_scm.patch). I don't know if the changes at EDS are temporary. Certainly, use at your own risk. Cheers, Ed. -- Coot est verendus 166c166,167 (eds-url (string-append eds-site /sfd/)) --- (two-letter-id (substring down-id 1 3)) (eds-url (string-append eds-site /dfs/ two-letter-id /))
[COOT] SSM bug
I have a reproducible crash when using SSM on a particular structure. It has 4 chains and coot crashes only if I try to SSM chain B on top of chain A (but not A on top of B or any other chain on top of A). What's the general procedure to report such bugs - do I turn on core dump or maybe I should submit the structure itself? I did build the latest coot (rev. 2623) to verify the bug. On Linux, it just crashes Coot, on Windows it crashed the system (as expected :) Ed. -- Coot est verendus
[COOT] karmic
In Ubuntu 9.10, coot appears to be fully compatible with compiz when running on Intel graphics card. So there is no need to disable the visual effects anymore. --
Re: [COOT] karmic
Excellent idea (although I would probably cheat and produce the video on the machine with nvidia card that has been always able to run coot/compiz combination). On a serious note, sometimes I have to project coot on a big screen from a laptop with intel graphics, and now I don't need to turn off compiz every time I do it (of course, it is a big question if rotating cubes, wobbly windows and fire spread across the screen is attractive or annoying; but at least I will have fun when they ask what kind of mac is that? :) Coot est verendus, Ed. On Fri, 2009-12-04 at 17:38 +, Paul Emsley wrote: Ed Pozharski wrote: In Ubuntu 9.10, coot appears to be fully compatible with compiz when running on Intel graphics card. So there is no need to disable the visual effects anymore. Hoorah! So will we get to see a youtube video of coot running an all molecule script (say), each face of the cube doing a different chain? Hehe... Paul. --
Re: [COOT] buggy coot 0.6-pre-1 r2264 on OS X 10.4.11
That may be because core dump is turned off (which is default on many Linux distros). If you are using bash, try ulimit -c to see if it's the case (it'll return the maximum allowed core size). To turn it on, issue ulimit -c unlimited command. For more details, see man bash (not man ulimit as it is shell command). It only affects the current shell. HTH, Ed. On Tue, 2009-09-08 at 19:12 -0700, Engin Ozkan wrote: That is actually a very reasonable request. Sorry for missing that. However, this bug does not leave any core dumps anywhere I could find, including in /cores. Engin On 9/8/09 10:58 AM, Paul Emsley wrote: Engin Ozkan wrote: Hi everybody, Using the revision 2283 on 10.5, I am seeing this whenever I am closing the application: /sw/bin/coot: line 5: 19785 Segmentation fault /sw/bin/coot-real $@ Yep, coot shuts down with a segmentation fault. I haven't tested most functionality and it has not affected my use of coot yet, but I assumed it might help to report it. This seems to be the same bug observed by Christian on a 10.4 machine, because I get the similar Preferences crash. Empty 0-coot.state.scm is also probably due to the crash during exiting. Dear MacCoot-bug-finders, It would be very useful (making the difference between a bug being probably not fixable to probably fixable) if you could send me the core dump analysis of coot. Coot will leave a core dump in /cores - at least it does for me (look for the latest one) $ gdb /sw/bin/coot-real /cores/cores. where send me that text output. Thanks, Paul --
Re: [COOT] autobuilder fails (was: ELFCLASS64)
I am trying to stop being lazy and just build coot for my system (64-bit Ubuntu Jaunty). I tried autobuilder scripts, which seem to be quite awesome, but so far fail in my hands. First few things were relatively obvious: I had to install the *-dev packages to get the pkgconfig to work. I hit the wall with the GtkGLExt. Then something weird happened - I turned off compiz and it went past GtkGlExt issue, but I can't reproduce it - it works now even after I turned the compiz back on. Now it tells me that I Must install goosh for guile. That I can't figure out how to do - can't find anything in repositories. This leads me to a fundamental question - why do I have to tweak my system and install additional packages (after I installed everything mentioned as pre-requisites for the autobuilder in the README)? My understanding of the autobuilding process was that the script downloads all the dependencies and configures them in autobuild folder. Take this goosh issue. I do have the goosh-1.3 folder in the appropriate place, why does the script fail to find it? This is reminiscent of my earlier issue when coot binaries were looking for libraries in /usr/lib instead of just getting them from coot/lib. This again indicates that something may be wrong with system configuration. Any ideas? Ed. On Tue, 2009-05-12 at 13:22 -0400, Ed Pozharski wrote: Didn't help. It must have something to do with my configuration. I have no problems on other machines running Hardy. Which executable actually requires this library? I put ldd $coot_real into the xxx/bin/coot script, and it does list many libraries in xxx/lib properly. However, the one in question is not listed (in fact, coot also complains about canberra-gtk-module, libgiogconf, libgvfsdbus, libgioremote-volume-monitor, but these are perhaps not critical so it does not crash). This may be irrelevant, but I made the following observations: - when coot crashes, it says ERROR: In procedure dynamic-link: - when I look in the source, the only place which has these very words (i.e. dynamic-link) is in scheme/my-readline.scm - it says (dynamic-link libguilereadline-v-12))) - libguilereadline-v-12 is in guile-1.6-libs, not 1.8 - moreover, coot/lib has libguilereadline-v-17, not 12 - there is /usr/lib32/libguilereadline-v-17, but not 12 I tried to remove/reinstall both guile-1.6-libs and guile-1.8-libs, and it didn't help. Ed. On Tue, 2009-05-12 at 00:34 +0100, Paul Emsley wrote: 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. OK, try this: in your xxx/bin/coot script, after the line export LD_LIBRARYN32_PATH add: LTDL_LIBRARY_PATH=$COOT_PREFIX/lib export LTDL_LIBRARY_PATH Paul. --
Re: [COOT] Graphics problem running Coot with EdUbuntu 8.10
It is not a Ubuntu problem. I have the same issue on my laptop, and it's because it has Intel onboard graphics chip. With NVIDIA cards (at least on all the desktops I've seen), coot runs fine when you enable compiz (of course, I do use proprietary nvidia drivers). On Tue, 2009-05-12 at 14:34 +1200, Shaun Lott wrote: Hi Stephen On the money - thanks! Running GNOME as the desktop environment, doing exactly as you suggest fixes the problem. GNOME was having other stability issues also, which caused some student frustration. Alternatively, using Xfce as the desktop environment worked right off the bat. I also tried KDE, and if anything it was worse than GNOME, plus I couldn't find where to disable Compiz. Hope this helps anyone else who may have struggled with this issue. cheers Shaun -- Dr J. Shaun Lott AgResearch Senior Lecturer in Structural Biology Laboratory of Structural Biology Maurice Wilkins Centre School of Biological Sciences 3a Symonds Street University of Auckland Private Bag 92019 Auckland 1142 New Zealand t : +64 9 3737599 x87074 f : +64 9 3737416 http://shaunlott.blogspot.com On 11 May 2009, at 17:51, Stephen Graham wrote: Hi Shaun, Have you tried turning off compiz? (System Preferences Appearance Visual Effects: Select 'None') Cheers, Stephen On 11/05/2009, Shaun Lott s.l...@auckland.ac.nz wrote: Hi Apologies if this problem has been dealt with elsewhere - I scanned the archives but couldn't see anything that looked similar. I'm about to use Coot as part of a graduate teaching exercise. Version 0.52 starts ok, and can load co-ords and maps, but whenever one clicks, the screen gets corrupted - see attached image. You can get a normal view back by rotating the molecule, but the whole user experience is a pretty frustrating one, as it is pretty much impossible to click on anything. The fault seems to be hardware and Coot version independent - it manifests in 0.5.2 and also using 0.6-pre-1-revision-1997-binary-Linux-i686-ubuntu-8.04.2, though less dramatically in the latter - just a grey screen rather than the corrupted one. The same thing occurs when using a Dell or an iMac running Ubuntu (don't ask...) So I'm guessing it's a(n) Ubuntu thing. The machine are running the same versrion of EdUbuntu 8.10, details as below. Has anyone else seen this? Does anyone have a fix? cheers Shaun cat /proc/version Linux version 2.6.27-7-generic (bui...@palmer) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11) ) #1 SMP Tue Nov 4 19:33:20 UTC 2008 -- Dr Stephen Graham Division of Structural Biology Wellcome Trust Centre for Human Genetics Roosevelt Drive Oxford OX3 7BN United Kingdom Phone: +44 1865 287 549 --
Re: [COOT] ELFCLASS64
Didn't help. It must have something to do with my configuration. I have no problems on other machines running Hardy. Which executable actually requires this library? I put ldd $coot_real into the xxx/bin/coot script, and it does list many libraries in xxx/lib properly. However, the one in question is not listed (in fact, coot also complains about canberra-gtk-module, libgiogconf, libgvfsdbus, libgioremote-volume-monitor, but these are perhaps not critical so it does not crash). This may be irrelevant, but I made the following observations: - when coot crashes, it says ERROR: In procedure dynamic-link: - when I look in the source, the only place which has these very words (i.e. dynamic-link) is in scheme/my-readline.scm - it says (dynamic-link libguilereadline-v-12))) - libguilereadline-v-12 is in guile-1.6-libs, not 1.8 - moreover, coot/lib has libguilereadline-v-17, not 12 - there is /usr/lib32/libguilereadline-v-17, but not 12 I tried to remove/reinstall both guile-1.6-libs and guile-1.8-libs, and it didn't help. Ed. On Tue, 2009-05-12 at 00:34 +0100, Paul Emsley wrote: 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. OK, try this: in your xxx/bin/coot script, after the line export LD_LIBRARYN32_PATH add: LTDL_LIBRARY_PATH=$COOT_PREFIX/lib export LTDL_LIBRARY_PATH Paul. --
[COOT] ELFCLASS64
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)? I'll be glad to provide further details. I also tried 64-bit binaries (rev. 1998, rhel-4-python-gtk2), but those crash anytime I try to load an MTZ file (fftw: BUG in executor: invalid plan). --
