Re: [COOT] AW: one coot function
i think what gerhard ment to say is: it would be good if you always could explain a bit: - which part of the docu you have read - what you have tried - and what exactly did not work as decribed there this allows for more focussed answers and will help the programmers to improve their documentation, too ... ingo On 26.01.2012 09:50, Stefan Gerhardt wrote: What about reading the manual ?? /ouups, that was me thinking loudly … *Von:*Mailing list for users of COOT Crystallographic Software [mailto:COOT@JISCMAIL.AC.UK] *Im Auftrag von *Dialing Pretty *Gesendet:* Donnerstag, 26. Januar 2012 04:55 *An:* COOT@JISCMAIL.AC.UK *Betreff:* one coot function Dear All, Will you please tell me how to set up a map in Coot in order to use the Fit Loop function in Calculate? Cheers, Dialing -- CRELUX GmbH Dr. Ingo Korndoerfer Head of Crystallography Am Klopferspitz 19a 82152 Martinsried Germany Phone: +49 89 700760210 Fax: +49 89 700760222 korndoer...@crelux.com www.crelux.com Amtsgericht München HRB 165552 - Managing Directors: Dr. Michael Schäffer, Dr. Ismail Moarefi This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. attachment: korndoerfer.vcf
[COOT] GThread-ERROR **: GThread system may only be initialized once.
Dear Paul, we have happily been running the coot-Linux-x86_64-centos-5-gtk2-python build on our Scientific Linux 6.1 (RHEL-6 clone) machines. In particular, version 3607 has been working very well for quite some time now. Today I tried to upgrade to version 3965, using coot-0.7-pre-1-revision-3965-binary-Linux-x86_64-centos-5-python-gtk2.tar.gz However this crashes after showing the coot logo: ... Good Afternoon Kay, Welcome to Coot. 0.7-pre-1 (revision 3965) [with guile 1.8.7 embedded] [with python 2.7.0 embedded] (set-display-intro-string Good Afternoon Dikay, Welcome to Coot. 0.7-pre-1 (revision 3965) [with guile 1.8.7 embedded] [with python 2.7.0 embedded]) Loading: mutate.py Loading: refmac.py Loading: libcheck.py Loading: gap.py Loading: fitting.py Loading: raster3d.py Loading: povray.py Loading: remote_control.py Loading: generic_objects.py Loading: ncs.py Loading: parse_pisa_xml.py Loading: cns2coot.py Loading: tips.py Loading: americanisms.py Loading: group_settings.py Loading: brute_lsqman.py Loading: coot_gui.py Coot Python Scripting GUI code found and loaded. Loading: tips_gui.py Loading: check_for_updates.py Loading: get_recent_pdbe.py Loading: shelx_extensions.py Loading: prodrg_import.py new prodrg_import.py Loading: clear_backup.py Loading: coot_toolbuttons.py INFO:: loading preferences file /home/dikay/.coot-preferences/coot_preferences.py Running python script /home/dikay/.coot-preferences/coot_preferences.py (set-filter-fileselection-filenames 1) (unset-sticky-sort-by-date) (set-colour-map-rotation-on-read-pdb 21.00) (set-colour-map-rotation-on-read-pdb-c-only-flag 1) (set-density-size 20.00) (set-swap-difference-map-colours 0) (set-colour-map-rotation-for-maps 14.00) (set-active-map-drag-flag 1) (set-idle-function-rotate-angle 1.00) (filter-fileselection-filenames-state) (get-active-map-drag-flag) (use-graphics-interface-state) GThread-ERROR **: GThread system may only be initialized once. aborting... /usr/local/src/new/coot-Linux-x86_64-centos-5-gtk2-python/bin/coot: line 247: 4557 Aborted (core dumped) $coot_real $@ The same problem was reported on May 23, 2011 by Richard Birkinshaw, without resolution. So is anybody successfully using the latest CentOS-5 x86_64 builds on CentOS-6 or SL-6 or RHEL6 ? And if so, what goes wrong in my case, and similarly for others, as reported? thanks, Kay -- Kay Diederichshttp://strucbio.biologie.uni-konstanz.de email: kay.diederi...@uni-konstanz.deTel +49 7531 88 4049 Fax 3183 Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz This e-mail is digitally signed. If your e-mail client does not have the necessary capabilities, just ignore the attached signature smime.p7s. smime.p7s Description: S/MIME Cryptographic Signature
Re: [COOT] GThread-ERROR **: GThread system may only be initialized once.
For the record, I hope/think that this is the same problem that is currently affecting the RedHat 5 builds too about which one or two others have contacted me. (We don't catch it because the automatic testing doesn't start the gui.) Paul. On 26/01/12 13:36, Bernhard Lohkamp wrote: Hi Kay, OK, my bad I guess. Am about to fix this. I will commit a quick fix until I permanently fix this issue. Seems to behave differently on different systems as I havent seen this error. If you want a quick fix: comment out (using #) or delete the following line in coot_load_modules.py (in COOT/share/coot/python): get_recent_pdbe.py, Hope this resolves the problem, B Dear Paul, we have happily been running the coot-Linux-x86_64-centos-5-gtk2-python build on our Scientific Linux 6.1 (RHEL-6 clone) machines. In particular, version 3607 has been working very well for quite some time now. Today I tried to upgrade to version 3965, using coot-0.7-pre-1-revision-3965-binary-Linux-x86_64-centos-5-python-gtk2.tar.gz However this crashes after showing the coot logo: ... Good Afternoon Kay, Welcome to Coot. 0.7-pre-1 (revision 3965) [with guile 1.8.7 embedded] [with python 2.7.0 embedded] (set-display-intro-string Good Afternoon Dikay, Welcome to Coot. 0.7-pre-1 (revision 3965) [with guile 1.8.7 embedded] [with python 2.7.0 embedded]) Loading: mutate.py Loading: refmac.py Loading: libcheck.py Loading: gap.py Loading: fitting.py Loading: raster3d.py Loading: povray.py Loading: remote_control.py Loading: generic_objects.py Loading: ncs.py Loading: parse_pisa_xml.py Loading: cns2coot.py Loading: tips.py Loading: americanisms.py Loading: group_settings.py Loading: brute_lsqman.py Loading: coot_gui.py Coot Python Scripting GUI code found and loaded. Loading: tips_gui.py Loading: check_for_updates.py Loading: get_recent_pdbe.py Loading: shelx_extensions.py Loading: prodrg_import.py new prodrg_import.py Loading: clear_backup.py Loading: coot_toolbuttons.py INFO:: loading preferences file /home/dikay/.coot-preferences/coot_preferences.py Running python script /home/dikay/.coot-preferences/coot_preferences.py (set-filter-fileselection-filenames 1) (unset-sticky-sort-by-date) (set-colour-map-rotation-on-read-pdb 21.00) (set-colour-map-rotation-on-read-pdb-c-only-flag 1) (set-density-size 20.00) (set-swap-difference-map-colours 0) (set-colour-map-rotation-for-maps 14.00) (set-active-map-drag-flag 1) (set-idle-function-rotate-angle 1.00) (filter-fileselection-filenames-state) (get-active-map-drag-flag) (use-graphics-interface-state) GThread-ERROR **: GThread system may only be initialized once. aborting... /usr/local/src/new/coot-Linux-x86_64-centos-5-gtk2-python/bin/coot: line 247: 4557 Aborted (core dumped) $coot_real $@ The same problem was reported on May 23, 2011 by Richard Birkinshaw, without resolution. So is anybody successfully using the latest CentOS-5 x86_64 builds on CentOS-6 or SL-6 or RHEL6 ? And if so, what goes wrong in my case, and similarly for others, as reported? thanks, Kay
Re: [COOT] how to optimize this part in order to have the green blobs disappear by Coot
I would be a bit more concerned with the apparent lack of fit of the model to the map. It looks as if there is unoccupied side chain density, and possibly side chains that don't occupy density. It is hard to tell from a snapshot, but if this is the case, make sure everything is in register first, then re-refine, having reset the temperature factors to something sensible, and then when you converge on something that fits and makes sense, re-assess the map. Lots of green density sitting on your model might indicate problems with scaling the data or with the temperature factor refinement. 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) On Jan 25, 2012, at 8:04 PM, Dialing Pretty wrote: Dear All, Will you please take a loot on the coot sscreenshot and give me some suggestions on how to further optimize in order to have the green blobs disappear by Coot? Cheers, Dialing
Re: [COOT] GThread-ERROR **: GThread system may only be initialized once.
On Jan 26, 2012, at 5:36 AM, Bernhard Lohkamp wrote: Hope this resolves the problem, B Seems to fix it on OS X -- Bill
Re: [COOT] Coot - 3D Anaglyph
Ha. Now that's just about where I went running (comments in the other thread on ligand restraints...). See what I mean? Got to watch your step...next run I'll bring my red/green glasses... On Thu, Jan 26, 2012 at 12:06 PM, William G. Scott wgsc...@ucsc.edu 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
Re: [COOT] New restraints, same name
Personally, I like the ability to at least have a sanity check of the HETNAM with the dictionary - and if they do not match - do not use it... Assuming people provide a unique name in their dictionary - even if it is FOO1, FOO2, etc - this could catch the issue. This assumes that the refinement programs output such information. For places that one cannot ensure the dictionary restraint file is proper, maybe a coot preference/configuration of ligands in which coot should not assume the loaded dictionary is correct. One could put LIG, DRG, XXX in it. If someone then manually reads in a restraint file - then you use it. Does coot save the location of dictionary files manually loaded? Ezra Paul Emsley wrote: Thanks to all contributors, I have been informed, educated and entertained. A bit of background perhaps... (it seems that I have been living in the 0.7 world long enough to forget that not everyone else is here). [T]he viewer programs don't care about the restraint dictionaries says Seth Harris - haha - in olden Coots that was the case... :) It is my hope that Coot will be used for comparison, evaluation, validation and manipulation of ligands in protein-ligand complexes and their electron density. My current obsession is with chemical structure diagrams - here's a recent screenshot: http://lmb.bioch.ox.ac.uk/coot/screenshots/Screenshot-example-2010-01-02.png ... and here's one I made earlier today, illustrating the sorts of problems I am trying to handle (PI3 Kinase ligand, 4a55): http://lmb.bioch.ox.ac.uk/coot/screenshots/Screenshot-Coot-prodrg-valence-problem.png amusing, eh? Anyway, to make the chemical diagram and the 3D bonding representation I need to construct a description of the ligand that contains bond orders. Hence restraints. So yes, let me emphasize that this is mostly for drawing pictures and I don't see the use case of refinement of multiple different ligand complexes as very useful. I do like Dale's idea - the use of HETNAM and synonyms - so, as I understand it, the PDB file has a residue called LIG and the dictionary has a comp-id of 2-(N-methylmethanesulfonamido)-6-(propan-2-yl)pyrimidine (or XYZ0123456 or whatever) and a HETNAM record in the PDB file provides the mapping. Is this a solution? It is attractive because it requires very little work from me. I did consider Judit's idea, i.e. check the atom names in the coordinates against the dictionary before bonding. I thought that there may be (too many?) pathological cases where the names did match (at least for ligand fragments) but the chemistry did not. Let me know if you think that I need not worry so much about that. This is relatively easy to do. However, this only solves the tangle problem - and I think that that for practical purposes that may be covered now as I have recently turned off restraints auto-loading for several special three-letter codes - one can (at least) see noddy bonding instead of a tangle. To answer Garib's point: yes, in Coot there is indeed a single table/dictionary of restraints, with the key/index being the comp-id/residue-name. It applies to all molecules. I had not before considered the option of embedding monomer restraints inside a Coot molecule - that might be a cleaner solution. I will ponder on that. It does mean that you will have to read restraints after reading coordinates though. And yes, I do occasionally wonder how computational chemistry software (Maestro, Vida for example?) solves this problem. Presumably such software is used to show several overlaying ligand structures (all called LIG?). And computational chemists like to see chemistry, and not just coloured sticks, right? Thanks, Paul.
Re: [COOT] New restraints, same name
On 26/01/12 21:48, Ezra Peisach wrote: Personally, I like the ability to at least have a sanity check of the HETNAM with the dictionary - and if they do not match - do not use it... Assuming people provide a unique name in their dictionary - even if it is FOO1, FOO2, etc - this could catch the issue. This assumes that the refinement programs output such information. I agree with this (except that, AFAICS, it is an issue for restraints generation, not refinement programs). For places that one cannot ensure the dictionary restraint file is proper, maybe a coot preference/configuration of ligands in which coot should not assume the loaded dictionary is correct. One could put LIG, DRG, XXX in it. If someone then manually reads in a restraint file - then you use it. I agree with this too - and is what I have now implemented (ok, a touch more work is needed, but this is how it will look). Does coot save the location of dictionary files manually loaded? Yes it does (dictionaries-read) Paul.
