Re: [COOT] Is there anything I can do to make X11 stable enough to use on 10.5.2
Bill I've been using 10.5.2 plus the X11 2.1.4 update from the Xquartz site, I haven't had problems with freezing lately, I _think_ not since this update. The main problem is that Exposé doesn't work properly not much help ... Phil (looking at a white Easter outside the bedroom window) On 23 Mar 2008, at 01:01, William Scott wrote: Hi Folks: I know I've asked before, but it is so frustrating to lose an hour of work, trying to convince myself that I won't get reamed this time. But I keep going back, like to some sort of abusive codependent relationship, to put it into California terms. I'm using a molecular graphics model building crystallography program called coot, but this happens with enough other X11 applications that I don't think it is the fault of coot. Prior to OS X 10.5, I never ever had a problem with X11. If I try to resize a window while the program is loading, it is a guarantee that the Xserver will freeze. However, if I try to be real careful, I can start to get work done, but then when some window or pop-up menu appears, a half hour or an hour into a session of work, I'll get a random freeze. I'm running 10.5.2 on intel (but this happens on all my 10.5.2 computers, ppc and intel) and the latest X11 from the update page, and when I sample the frozen processes I get this as output: Sample of X11.txt x11_hosing.txt My kids want to know why I swear at the computer so much. I'm almost ready to reformat the disk and install ubuntu linux. Thanks. Bill Scott
[COOT] phosphothreonine
1) If I phosphorylate a THR, it comes up with the wrong chirality at CB. Looking at the dictionary file generated libcheck_TPO.cif, for some reason it specified it a both chirality which is wrong TPO chir_02 CB CA CG2OG1 both Editing this to match THR.cif TPO chir_02 CB CA OG1CG2 positiv gives the correct chirality (after rebuild or regularisation) 2) Since there are no rotamers for TPO, I tried using the chi angles editing,but picking the CA-CB bond rotates the main chain instead of the side chain Phil
Re: [COOT] Coot 0.5 released
o FEATURE: Active site hilighting. Cheep and cheerful solid modelling of ligand and neighbouring residues [Herb Klei]. cheep, cheep...
Re: [COOT] Atoms
It would seem sensible to do this if the element column is not present (which of course it should be ...) Phil On 3 Oct 2008, at 10:33, Paul Emsley wrote: 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] defining NCS-related chains
On the subject of NCS chains, Paul, I note that you are still using SSM superposition in determining NCS operators (unless it's been changed _very_ recently), rather than the LSQ algorithm which would preserve the sequence register. SSM gets the wrong answer in some cases, eg in some coiled-coil proteins such as BAR domains, where an out-of-register SSM superposition can give a lower score than the in- register one, and of course the correct NCS must be in register. You did say quite a long time ago that you going to change this :-) Best wishes Phil
Re: [COOT] Zinc-density
As a matter of interest, why do you have to do this? Why doesn't coot know the Zn is there, it's in the PDB file? Isn't this a bug? : -) Phil On 13 May 2009, at 23:45, Paul Emsley wrote: 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] Coot fails to read numeric chain IDs
why does Coot ignore these atoms renumbered back to 1 beyond 1? Shouldn't it just ignore the irrelevant atom number? Phil On 3 Jun 2009, at 09:19, Kevin Cowtan wrote: Hi! Hybrid-36 (initial idea from Ralph Grosse Kunstleve, I think) works around this problem by allowing higher numbered atoms to be numbered in base 36 starting from A. CCP4 v6.1.1 and recent versions of Coot support this, as does phenix.refine. http://cci.lbl.gov/hybrid_36/ However, last time I checked, it wasn't available in refmac. I think refmac ignores atom numbers on read, and writes out its own atom numbers sequentially, looping at 10. As a result, you cannot read a refmac output PDB file with more 10 atoms into Coot or any other CCP4 application without somehow renumbering the atoms first. Garib: Have I got that right? Is that still the case in recent versions? Kevin Edward Miller wrote: Hey Paul, I believe I have figured out the problem - but not the solution. On closer inspection, it wasn't just the numerically labelled chain IDs that weren't read, a few of the alphabetical chains were also not read. What happens is REFMAC restarts atom numbering once 10 atoms are reached when outputting the refined coordinates. COOT was reading in the first 9 atoms, numbered 1-9 by REFMAC, then the second 9 atoms, again numbered 1-9 by REFMAC. At this point, however, REFMAC for some reason made the next atom 10 and then restarted numbering at 1. This atom, numbered 10, was not read by COOT and nor where any subsequent atoms. The input coordinates that I used for REFMAC, which again consisted of 60 chains, was created by combining sets of 10mers, thus the atom numbering restarted after each 10 chains. REFMAC had no problem refining these coordinates and COOT had no problem reading these coordinates. To further confirm that COOT is failing once it reads atom 10, I wrote a little perl script to properly renumber the atoms in the REFMAC refined coordinates. In this file, there are correctly 246960 atoms. Within my perl script, I formatted the output such that the atom numbers eat into the spaces after ATOM like so: ATOM 246960 O LEU 7 736 64.294 96.393-111.576 1.00 34.97 I see now that the last atom COOT reads in is atom number 9. Perhaps, I fear, this is a problem with the PDB format - that the column width for atom numbers can not accommodate more than 9 atoms. Ed On Tue, Jun 2, 2009 at 9:39 AM, Paul Emsley paul.ems...@bioch.ox.ac.uk mailto:paul.ems...@bioch.ox.ac.uk wrote: 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] sequencing gui
OK thanks. I tried a different example, which did give me a (wrong) assignment - is there any way of picking an alternative? What partly confused me before and again was that this command assigns the sequence but doesn't build the side chains - you have to use the Fill Partial Residues command, I suppose Also if I go back to the GUI for the same molecule, it displays 2 sequences Thanks again Phil --- then cootaneer iv: 0 seq.size: 1 debug pythoning and MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ in assign_sequence_from_string storing sequence: MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ for chain id: A (assign-sequence-from-string2 A MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ ) Sequence: ?KIEFT? Confidence: 0.912518 On 4 Jun 2009, at 13:37, Bernhard Lohkamp wrote: I guess you didnt give it a chain id. When sequencing the closest fragment this information is required (maybe it shouldnt, or at least it should give the appropriate warning - I will look into it at some point). B I'm trying to understand the Extensions- Dock sequence dialogue. How does it work? I've tried Place helix here Select Dock Sequence choose Helix molecule Load sequence from a file click Sequence closest fragment then I get assign-sequence-from-file2 /Users/pre/Documents/Talks/ Crystallography/LMB-2009/MapFitting/Examples/amph2.seq) iv: 0 seq.size: 1 debug pythoning and MAEMGSKGVTAGKIASNVQKKLTRAQEKVLQKLGKADETKDEQFEQCVQNFNKQLTEGTRLQKDLRTYLASVKAMHEASKKLSECLQEVYEPEWPGRDEANKIAENNDLLWMDYHQKLVDQALLTMDTYLGQFPDIKSRIAKRGRKLVDYDSARHHYESLQTAKKKDEAKIAKPVSLLEKAAPQWCQGKLQAHLVAQTNLLRNQAEEELIKAQKVFEEMNVDLQEELPSLWNSRVGFYVNTFQSIAGLEENFHKEMSKLNQNLNDVLVSLEKQHGSNTFTVKAQPSDSAPEKGNKSPSPPPDGSPAATPEIRVNHEPEPASGASPGATIPKSPSQLRKGPPVKHTPSKEMKQEQILSLFDDAFVPEISVTTPSQFEAPGPFSEQASLLDLDFEPLPPVASPVKAPTPSGQSIPWDLWEPTESQAGVLPSGEPSSAEGSFAVAWPSQTAEPGPAQPAEASEVVGGTQEPGETAASEATSSSLPAVVVETFSATVNGAVEGSTTTGRLDLPPGFMFKVQAQHDYTATDTDELQLKAGDVVLVIPFQNPEEQDEGWLMGVKESDWNQHKELEKCRGVFPENFTERVQ apply the sequence info here then cootaneer ERROR:: the input contains an invalid chain and/or sequence BL ERROR:: something went wrong assigning the sequence What should I have done? (Coot 0.6-pre 1 1941, OSX) Best wishes Phil
Re: [COOT] sequencing gui
Ah OK thanks Phil On 4 Jun 2009, at 15:05, Kevin Cowtan wrote: It's very unlikely to be right on anything much shorter than 12 residues. The confidence scores are a bit gung-ho. Phil Evans wrote: OK thanks. I tried a different example, which did give me a (wrong) assignment - is there any way of picking an alternative? What partly confused me before and again was that this command assigns the sequence but doesn't build the side chains - you have to use the Fill Partial Residues command, I suppose Also if I go back to the GUI for the same molecule, it displays 2 sequences Thanks again Phil --- then cootaneer iv: 0 seq.size: 1 debug pythoning and MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ in assign_sequence_from_string storing sequence: MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ for chain id: A (assign-sequence-from-string2 A MHHLVPRGSHMIPSITAYSKNGLKIEFTFERSNTNPSVTVITIQASNSTELDMTDFVFQAAVPKTFQLQLLSPSSSVVPAFNTGTITQVIKVLNPQKQQLRMRIKLTYNHKGSAMQDLAEVNNFPPQSWQ ) Sequence: ?KIEFT? Confidence: 0.912518 On 4 Jun 2009, at 13:37, Bernhard Lohkamp wrote: I guess you didnt give it a chain id. When sequencing the closest fragment this information is required (maybe it shouldnt, or at least it should give the appropriate warning - I will look into it at some point). B I'm trying to understand the Extensions- Dock sequence dialogue. How does it work? I've tried Place helix here Select Dock Sequence choose Helix molecule Load sequence from a file click Sequence closest fragment then I get assign-sequence-from-file2 /Users/pre/Documents/Talks/ Crystallography/LMB-2009/MapFitting/Examples/amph2.seq) iv: 0 seq.size: 1 debug pythoning and MAEMGSKGVTAGKIASNVQKKLTRAQEKVLQKLGKADETKDEQFEQCVQNFNKQLTEGTRLQKDLRTYLASVKAMHEASKKLSECLQEVYEPEWPGRDEANKIAENNDLLWMDYHQKLVDQALLTMDTYLGQFPDIKSRIAKRGRKLVDYDSARHHYESLQTAKKKDEAKIAKPVSLLEKAAPQWCQGKLQAHLVAQTNLLRNQAEEELIKAQKVFEEMNVDLQEELPSLWNSRVGFYVNTFQSIAGLEENFHKEMSKLNQNLNDVLVSLEKQHGSNTFTVKAQPSDSAPEKGNKSPSPPPDGSPAATPEIRVNHEPEPASGASPGATIPKSPSQLRKGPPVKHTPSKEMKQEQILSLFDDAFVPEISVTTPSQFEAPGPFSEQASLLDLDFEPLPPVASPVKAPTPSGQSIPWDLWEPTESQAGVLPSGEPSSAEGSFAVAWPSQTAEPGPAQPAEASEVVGGTQEPGETAASEATSSSLPAVVVETFSATVNGAVEGSTTTGRLDLPPGFMFKVQAQHDYTATDTDELQLKAGDVVLVIPFQNPEEQDEGWLMGVKESDWNQHKELEKCRGVFPENFTERVQ apply the sequence info here then cootaneer ERROR:: the input contains an invalid chain and/or sequence BL ERROR:: something went wrong assigning the sequence What should I have done? (Coot 0.6-pre 1 1941, OSX) Best wishes Phil
[COOT] NCS
Is there a way for Copy NCS residue range to copy to a subset of NCS- related chains (eg from B to only, not to A D)? Phil
Re: [COOT] Coot and Zalman Stereo
Be careful how you look at it. As far as I can from trying it here, the stereo effect is very critically dependent on the vertical position of your eyes relative to the screen normal (or screen tilt if you like). Try tilting the screen Phil On 8 Sep 2009, at 17:55, Paul Shaffer wrote: Hi All, I recently acquired a Zalman 3D 22inch monitor with much anticipation. However, building the latest pre-release of Coot and invoking zalman stereo mode, it did not work. There are two images being displayed, but they are both displayed on all 1050 lines rather than alterating even and odd lines to give the left and right eye images. What I believe to be the relevant facts are these, the OS is RHEL3 with the latest nVidia linux drivers and coot version 2283 built using the auto-building script for a gtk1 build with python both enabled or disabled. The log files from compiling coot and the numerous dependancies looks ok without any obivous errors. Any suggestions? Is this a product of an outdated OS? Thanks in advance, Paul
Re: [COOT] Stand-Alone Coot - 0.6.2 pre-release svn rev. 3072 OS X 10.6 64-bit, phenix-compliant
Hi Bill I just installed this but it seems to have put everything in /Library/bin, /Library/etc and /Library/lib rather than in /Library/Coot Is this just me? Good luck in the struggle Phil On 3 Aug 2010, at 02:06, William G. Scott wrote: Sorry I haven't done this until now. Been distracted by the struggle for survival. http://sage.ucsc.edu/~wgscott/xtal/wiki/index.php/Stand-Alone_Coot#Version_0.6.2-pre-1-3072
Re: [COOT] Stand-Alone Coot - OS X : correction
pretty ... On 4 Aug 2010, at 13:22, Paul Emsley wrote: On 04/08/10 02:40, William Scott wrote: Dear Coot OS X people: Yesterday I put a package on the server that wrongly installed into /Library instead of /Library/Coot If you installed it, you can either install the replacement or manually move bin, share, etc and lib into /Library/Coot (which you probably need to create). http://sage.ucsc.edu/~wgscott/xtal/wiki/index.php/Stand-Alone_Coot#Version_0.6.2-pre-1-3072 http://sage.ucsc.edu/%7Ewgscott/xtal/wiki/index.php/Stand-Alone_Coot#Version_0.6.2-pre-1-3072 And just to encourage you to try out Bill's handywork, there is something new (eye candy?) under Display Manager - [Maps] Properties
[COOT] Colour by chain
If I colour by chain (my preferred option), metal ions disappear 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 Phil
Re: [COOT] Colour by chain
On 16 Nov 2010, at 13:22, Paul Emsley wrote: Dear Phil, Sorry for the delay, I am only just back from somewhat extensive travels. On 01/11/10 12:26, Phil Evans wrote: If I colour by chain (my preferred option), metal ions disappear Thanks for the notification of this bug. It is fixed now, rev 3245. thanks 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 Sphere refine is simply a thin layer around the refine-residues function which takes a list of residue specs - that gives you enough control, I hope. (You can also trivially change the radius in sphere refine.) Paul. How do you change the radius? I had a long chat to Bernhard about this. My feeling is that in order to avoid user consternation ((c) George Sheldrick), RS refinement in Coot should _never_ move something into space already occupied by another part of the same molecule (zero occupancy excepted). I realise there are implementation difficulties, but I do think this is a major problem. Phil
Re: [COOT] Colour by chain
That doesn't work in my OSX coot (maybe an oldish version 3072), no button appears The simpler command doe:s coot_toolbar_button(Sphere Refine, sphere_refine(5.0), reset-view.svg) Phil On 19 Nov 2010, at 08:26, Bernhard Lohkamp 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 Sphere refine is simply a thin layer around the refine-residues function which takes a list of residue specs - that gives you enough control, I hope. (You can also trivially change the radius in sphere refine.) Paul. How do you change the radius? The pythonic function sphere_refine takes an optional argument which is the radius (default is 3.5A). If you have the sphere refine function as a toolbutton (which I believe you have now) you can change the function in your toolbuttons file ($HOME/.coot-preferences/coot_toolbuttons.py) to say e.g. for radius 5A: coot_toolbar_button(Sphere Refine, sphere_refine(5.0), icon_name=reset-view.svg, tooltip=RSR around active residue) Does this help? B -- *** Dr. Bernhard Lohkamp Assistant Professor Div. Molecular Structural Biology Dept. of Medical Biochemistry and Biophysics (MBB) Karolinska Institutet S-17177 Stockholm Sweden phone: (+46) 08-52487651 fax: (+46) 08-327626 email: bernhard.lohk...@ki.se
[COOT] Libraries for RNA
This is a coot/refmac problem, but mainly coot I think, and I didn't want to cross-post. I'm deeply confused about atom residue naming for nucleic acids. There are several groups here working with RNA, and I recently broke coot for them, by installing the latest experimental refmac, and more particularly it's new dictionaries, into directory $CLIBD_MON. These dictionaries use what I believe are the most recent naming conventions, ie RNA residue type are A, G, U, C (not Ar etc), and DNA residues are DA, DG, DT, DC. Also ribose atoms are named with ' rather than with *. Thus AFAICS there are two name sets here 1. Old names: residue names Ar, Gr, Ur, Cr for RNA and * in the ribose atom names. 2. New names: residue names A, G, U, C for RNA and ' in the ribose atom names. The coot script (in COOT/bin/coot) by default picks up dictionaries from $CLIBD_MON (with new names now), unless I uncomment the line COOT_REFMAC_LIB_DIR=$COOT_PREFIX/share/coot/lib (and the corresponding EXPORT command) in which case it uses Coot dictionaries (in COOT/share/coot/lib/data/monomers), which use old names There are then the following cases: 1) if I leave Coot pointed at the (new) refmac dictionaries, then regularisation fails, both with files with old names (since they don't match the dictionaries) and with a file which I've edited to the new name convention (since Coot automatically and inconveniently converts a new-name file to old names) 2) if I point Coot to its own dictionaries, then files with both old new name conventions work, but new names are converted to old names, so output files will be like that Refmac with the new dictionaries seems to be able to read RNA files with either new or old naming, and preserve the naming scheme. So my question is: how do I set up a system which will work with Coot, Refmac, and preferably Molprobity and Phenix too? What are we _supposed_ to do? Phil PS: 1) Are the atom naming conventions described anywhere in an intelligible fashion? I found it hard to find things on the RSCB web site, particularly for hydrogen atom names 2) the new dictionaries from the Refmac site seem to have the old (v2?) hydrogen names for amino-acids, at least as far as I can tell from the hydrogen names given by Molprobity which I believe are in the new v3 convention (see PS point 1)
Re: [COOT] Sigma levels of ncs averaged maps
Why do you want to quote sigma level anyway? It's more or less meaningless for the reasons you give. Stick to e/A^3 /flame Phil On 22 Dec 2010, at 22:02, Dale Tronrud wrote: Hi, I have a crystal structure at 3A resolution with six copies in the asu. When I average the map over the ncs I find that the original 2Fo-Fc style map has a sigma of 1.5 at 0.3 e/A^3. When I adjust the contour level of the averaged map to match, by eye, the level of the unaveraged map I find them equivalent at a sigma of 2.6 at 0.28 e/A^3. These results imply that the sigma level of the original map was 0.2 e/A^3 and the averaged map was 0.11 e/A^3. The sigma of a 2Fo-Fc style map is not an estimate of uncertainty, of course, because nearly everything in the map is signal. It is just a measure of the variability of the signal, i.e. the rms. With averaging the signal should be preserved and the noise reduced, but the noise of a 2Fo-Fc map is small compared to the signal. How is it that the rms of my averaged map drops to half of the unaveraged value and yet the electron density looks about the same when contoured at the same e/A^3 (0.3 vrs 0.28)? I guess the real question is, how does Coot calculate the sigma of an averaged map? You can't calculate the rms over the asymmetric unit because the asymmetric unit is many millions of unit cells in size (and hugely variable depending on small changes in the ncs operators). The problem at hand is that I want to quote the sigma level I insisted upon when creating water molecules and think it will sound weird if I say I used a value of 12, which I did. The numbers just don't seem right to me so I'd like a little reassurance. Dale Tronrud
Re: [COOT] Python problem
Is that dangerous? If I move it I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site.pyc after moving that I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc and so on I guess Phil On 4 May 2011, at 12:28, Paul Emsley wrote: On 04/05/11 12:21, Phil Evans wrote: I've just acquired a new MacBookPro and cloned everything from my old one across to it, running the same 10.6.7 system When I try to run coot I get a Python error, see below, both on the version copied across from where it worked, and also from the latest build from Bill Scott any ideas? Phil ... snip sbase monomer dir: /usr/local/CCP4versions/ccp4-6.2.0/share/sbase Reading coordinate file: /Library/Coot/share/coot/standard-residues.pdb PDB file /Library/Coot/share/coot/standard-residues.pdb has been read. Spacegroup: P 1 Cell: 40.631 109.18 93.243 90 90 90 initalize graphics molecules...done. (filter-fileselection-filenames-state) (get-active-map-drag-flag) ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site.pyc Delete /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/*.pyc perhaps. Paul.
Re: [COOT] Python problem
OK that worked thanks I'm not sure whether these files got copied over from my old machine - I didn't do the copy myslef Phil On 4 May 2011, at 13:16, Paul Emsley wrote: On 04/05/11 13:11, Phil Evans wrote: Is that dangerous? Not really, python makes the pyc files again (I understand). If I move it I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site.pyc after moving that I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc and so on I guess So I understand after a bit more googling. I should have recommended some sort of find: $ find /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6 -name *.pyc -delete
Re: [COOT] Python problem
I did delete the *.pyc files in the system directories, and they have now reappeared I've also edited the coot wrapper to remove the system directories as suggested by Bill. All seems to work now thanks to everybody Phil On 4 May 2011, at 15:29, Ben Eisenbraun wrote: On Wed, May 04, 2011 at 01:16:29PM +0100, Paul Emsley wrote: On 04/05/11 13:11, Phil Evans wrote: Is that dangerous? Not really, python makes the pyc files again (I understand). Yes, but you're deleting compiled python objects from _system_ directories, and since normal users can't write to those directories, they will be recompiled and then thrown away every time python is run and those modules are imported. If I move it I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site.pyc after moving that I then get ImportError: Bad magic number in /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/os.pyc and so on I guess The problem is probably the PYTHONPATH setting in the coot wrapper script. If you're using a recent Fink/Bill Scott build of Coot, then it is using Python 2.7, and putting the 2.5 and 2.6 directories in the PYTHONPATH causes the interpreter to barf on start up. There was a discussion about this on the CCP4bb a couple months ago: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A1=ind1103L=CCP4BB#25 -ben -- | Ben Eisenbraun | SBGrid Consortium | http://sbgrid.org | | Harvard Medical School | http://hms.harvard.edu |
Re: [COOT] Coot for OSX 10.6
Thanks for that, Bill, you're a star! Two things: 1) what is supposed to happen in real-space refinement to residues with multiple conformations? They seem to be ignored when I do it 2) I get a crash on trying to add an OXT atom to a C-terminus /usr/local/bin/coot: line 7: 3158 Segmentation fault /Library/Coot/bin/coot-real $@ Phil On 31 Oct 2011, at 20:03, William Scott wrote: Hi Phil: I apologize for not having put it on line. It is now here: http://sage.ucsc.edu/xtal/coot/coot-0.7-pre-1-628-10.6.tgz Bill On Oct 31, 2011, at 6:36 AM, Phil Evans wrote: Where is the latest 10.6version? On 31 Oct 2011, at 13:35, William G. Scott wrote: Hi Phil: I haven't been able to compile coot since 11 September, due to a change in the code. I've got a 10.6.8 version of that too, but nothing newer I am afraid. Sorry. Bill On Oct 31, 2011, at 5:11 AM, Phil Evans wrote: As I understand it, Bill Scott now only builds Coot for OSX 10.7: is that right? At least his recent stand-alone builds don't seem to work with 10.6 Is there an up-to-date(ish) Coot build for 10.6? I hesitate to build it myself and I dislike Fink Phil William G. Scott Contact info: http://chemistry.ucsc.edu/~wgscott/
Re: [COOT] DB-loop
? eg if Number = 4, then there might be 2 picked residues on either end of the loop to assume are more-or-less correct (even if not fixed)? On 30 Jan 2012, at 16:03, Judit Debreczeni wrote: On 30 January 2012 14:47, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: Can someone explain Extensions-Modelling-DB Loop or point to documentation (I've tried Google)? What are Number of residues for basis? Phil Assume we have a missing loop that we would like to get built. The conformation of the newly built loop candidates will depend on the residues we have already modeled on both sides of the gap. My understanding is that residues picked for basis (i.e. residues already modeled) will be included in the search and used as starting points for the new loop (and not just treated as correct). J.
[COOT] OSX OXT crash
On OSX coot still crashes on adding OXT atoms to C-terminus. This is Bill Scott's build of 0.7-pre-1 4125 for OSX10.6 This seems to have been a longstanding proble, which I've never seen on Linux Phil /usr/local/bin/coot: line 7: 10159 Segmentation fault /Library/Coot/bin/coot-real $@
Re: [COOT] Problem with Coot Density Fit Analysis with PHENIX map coefficients
(hesitating to restart an old flame war) There has been a long-standing argument about scaling of electron density maps, with many people deprecating sigma-scaling, for two reasons 1) in 2Fo-Fc type maps, sigma = RMS density is a function among other things of the solvent content (smaller with high solvent content) 2) in difference maps Fo-Fc type, as the model improves, sigma gets smaller (ideally = 0). Sigma contouring is useful to pick out the largest features though. Scaling even approximately to e/A^3 (i.e. scaling Fobs to Fcalc) is consistent across solvent content and model quality, though still affected by resolution and other things, and generally should be preferred in my opinion. Sharpening map coefficients may also affect the scale Phil On 17 Jan 2013, at 15:48, Nat Echols nathaniel.ech...@gmail.com wrote: On Thu, Jan 17, 2013 at 3:16 AM, Pedro M. Matias mat...@itqb.unl.pt wrote: To clarify my previous e-mail, in both cases the maps are being calculated from weighted coefficients from an MTZ file output by the program. I tried calculating a weighted 2Fo-Fc map in CCP4i using the PHENIX MTZ file and the end-result (red bars) was the same. If I had to guess, I'd say that the output from Refmac is on an approximately absolute scale, i.e. the volume-scaled density values resemble the actual electron densities expected for the model. (I say approximately because the absence of F(0,0,0) and various FFT artifacts pretty much guarantee that the values are not actually accurate, just on the same order of magnitude.) This is presumably done by scaling F(obs) to F(calc). Maps from Phenix are definitely *not* on an absolute scale, however, and I guess the same must be true for BUSTER. Since everyone is used to looking at sigma-scaled maps this has not been a problem in the past; I don't think older versions of Coot had this problem either. You are not the first person to complain about this, for what it's worth. -Nat
Re: [COOT] Coot 0.8.1
I'm pretty sure the Aimless fails reported in the nightly builds are OK - I've changed some things so that you get different numbers Phil On 15 Dec 2014, at 18:11, Marcin Wojdyr woj...@gmail.com wrote: Congratulations! CCP4 nightly builds also include coot 0.8.1 now. It's a bigger bundle, containing also free-only-for-academics programs. Linux version should work on all Linux distros from the times of RHEL4 to today: http://devtools.fg.oisin.rc-harwell.ac.uk/nightly/ For OSX (10.6+) we have official build (Intel Compiler): http://www.ccp4.ac.uk/dev/nightly/ and one built with Apple LLVM 6.0, at the same location as Linux. (We don't have own Windows build, we'll take it from Bernhard.) Marcin On 15 December 2014 at 17:32, Paul Emsley pems...@mrc-lmb.cam.ac.uk wrote: We are pleased to announce Coot Release 0.8.1. (Basically a bug-fix release.) Redhat, CentOS, OpenSuse and Ubuntu binaries will appear here shortly: http://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/binaries/release/ WinCoot here hopefully: http://www.ysbl.york.ac.uk/~lohkamp/software/binaries/stable/ Paul. -- o CHANGE: Generic Dislay Objects dialog improved. o CHANGE: Water validation dialogs are now transient o CHANGE: Ctrl-R for Rock View o CHANGE: Least Squares Fit dialog now remembers its values o BUG-FIX: stippling for line and text geometry and environment distances updated o BUG-FIX: Jiggle fit moves atoms with zero occupancies. o BUG-FIX: Problem with CA-Zone - Mainchain fixed. o BUG-FIX: The amount that the other atoms ove with moving the picked atom has been reduced (but is configurable) o BUG-FIX: Sort chains and residues has been fixed. o BUG-FIX: Add Template Keybindings for Python now works
[COOT] NCS ligand
Hi I've got 4 molecules in the asu (chains A,B,C,D), and have just built a peptide ligand as chain S on to chain D. Is there an easy way to copy it to the right position on the other chains, or do I have to put it into chain D? Phil
[COOT] Copy NCS residue range
In Extensions-NCS-Copy NCS Residue Range the first window asks for the Master chain, but this seems not to work. As far as I can see, you have to set the Master Chain in the Draw-NCS Ghost Control window This looks like a bug, I think Phil
Re: [COOT] XQuartz 2.8.0_beta1 is not compatible with COOT
Oh the joys of dynamic libraries Sent from my iPad > On 2 Feb 2021, at 02:22, William Scott wrote: > > Hi Phil: > > I think the problem is that the new installer introduces a new launchd file > that changes the $DISPLAY > > I gzipped /Library/LaunchAgents/org.xquartz.startx.plist > > logged out/in > > now it behaves. > > The new version has an obsolete library file > >version: coot-bin requires version 4.0.0 or later, but libGL.1.dylib > provides version 1.0.0 > > Bill > > > >> On Feb 1, 2021, at 5:36 PM, William Scott wrote: >> >> Hi Phil: >> >> I just replicated the problem (and doubled my blood pressure). After >> restoring, I was finally able to get coot to launch after activating (the >> original) XQuartz manually, and then launching it from an xterm. It isn’t a >> path issue, but some Apple control-freak permission issue, eg: >> >> >> I still haven’t figured out how to get it to work in my normal terminal >> application. >> >> This is some kind of metaphor for what my life has devolved into. I’ll post >> again if I can figure out a solution. >> >> Peace and joy, >> >> Bill >> >> >> >> >> >> >>>> On Feb 1, 2021, at 2:07 PM, Phil Evans wrote: >>> >>> >>> I’ve just tried several times to install Xquartz 2.7.11 (MacOS Catalina), >>> but it crashes as soon as it starts >>> Any ideas? I _think_ that was the version I was using before, though maybe >>> I should back to an even earlier version >>> I did logout, reboot, reinstall etc >>> >>> Phil >>> >>> >>> >>>> On 1 Feb 2021, at 21:44, Huw Jenkins >>>> <288da93ae744-dmarc-requ...@jiscmail.ac.uk> wrote: >>>> >>>>> On 1 Feb 2021, at 21:37, Paul Emsley wrote: >>>>> >>>>> I take it to mean the XQuartz 2.8.0 doesn't distribute the library >>>>> against which Coot (0.9.x) is linked by CCP4 and CCPEM. >>>> >>>> As far as I can tell this is a bug in XQuartz 2.8.0_beta1 that has now >>>> been fixed: >>>> >>>> https://github.com/XQuartz/XQuartz/commit/e529e54f7a79459eeca5d09870d6d0aa157dd468 >>>> >>>> as XQuartz 2.7.11 has: >>>> >>>> /usr/X11/lib/libGL.1.dylib: >>>>/opt/X11/lib/libGL.1.dylib (compatibility version 4.0.0, current >>>> version 4.0.0) >>>> >>>> >>>> Huw >>>> >>>> >>>> To unsubscribe from the COOT list, click the following link: >>>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 >>>> >>>> This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing >>>> list hosted by www.jiscmail.ac.uk, terms & conditions are available at >>>> https://www.jiscmail.ac.uk/policyandsecurity/ >>> >>> >>> To unsubscribe from the COOT list, click the following link: >>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 >>> >> > To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
Re: [COOT] XQuartz 2.8.0_beta1 is not compatible with COOT
Is this a Coot problem or an Xquartz problem? Just hit this: other things work fine with this Xquartz Phil > On 1 Feb 2021, at 19:43, Jason Key wrote: > > Hi COOT users, > > A message for Mac users of COOT - > On Friday, XQuartz began prompting users with an update to XQuartz > 2.8.0_beta1. > This update is not compatible with the COOT provided for macOS by CCP4 or > CCPEM. > You will see an error along these lines: > > ''' > dyld: Library not loaded: /usr/X11/lib/libGL.1.dylib > Referenced from: /programs/i386-mac/ccp4/7.1/ccp4-7.1/libexec/coot-bin > Reason: Incompatible library version: coot-bin requires version > 1.2.0 or later, but libGL.1.dylib provides version 1.0.0 > ''' > > Skip the 2.8.0_beta1 update. If you have already updated your XQuartz, > you can downgrade to XQuartz 2.7.11 and COOT should work again. Be > sure to log out and log back in after XQuartz updates. > > Cheers, > Jason > -- > Jason Key, PhD > SBGrid Consortium, Harvard Medical School > > > > To unsubscribe from the COOT list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 > > This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list > hosted by www.jiscmail.ac.uk, terms & conditions are available at > https://www.jiscmail.ac.uk/policyandsecurity/ To unsubscribe from the COOT list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=COOT=1 This message was issued to members of www.jiscmail.ac.uk/COOT, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
