Re: [ccp4bb] iMosflm in 6.1 under OS X
Dear Engin, Yep, I can reproduce this using a binary installation myself - that would be a bug. We (CCP4) will look into it and get a fix to you as soon as possible. Thanks for the report, Graeme CCP4 Support Team -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Engin Ozkan Sent: 18 December 2008 06:10 To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] iMosflm in 6.1 under OS X Now that everything with coot and imosflm has been settled, how about sftools? I am getting errors when I try to open an sftools window with ccp4i, with 6.1.0. I get the same error with a fink-installed mac version, and a linux installation. Here is the error: bad window path name ".main.canvas.contents.param_1.body" bad window path name ".main.canvas.contents.param_1.body" while executing "pack $wframe.body -side top -fill x" (procedure "update_folder_display" line 23) invoked from within "update_folder_display 1 sftools_PROJECT view" invoked from within ".w_sftools_PROJECT.main.canvas.contents.param_1.top.but invoke" (command bound to event) Any ideas? Engin William G. Scott wrote: > More specifically, issue > > fink selfupdate-cvs (or fink selfupdate-rsync) fink install itcl itk > iwidgets tdom tkimg tktreectrl > > > > > On Dec 17, 2008, at 7:56 AM, Andrzej Lyskowski wrote: > >> Hi, >> >> I've just upgraded my fink distro and was wondering what else has to >> be done concerning configuration in order to make the iMosflm run on >> Mac OS. >> So far I'm getting the following error: >> >> Error in startup script: unknown namespace in import pattern "itcl::*" >>while executing >> "namespace import itcl::*" >>(file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/src/imosflm.tcl" >> line 91) >>invoked from within >> "source $env(IMOSFLM)" >>(file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl" line >> 111) >> >> Regards, Andrzej
Re: [ccp4bb] CCP4 6.1.0 release and CCP4MG
Dear Victor, The CCP4mg package is just about to be updated to version 2 built around Qt rather than the old Python/Tcl/Tk version. The former version was highly platform specific and would have required rather a large number of system permutations - this would make the load on the server as you have already mentioned rather worse. The new version will be just "linux" and we will begin to bundle it as soon as it has been released. In the meantime you can download CCP4mg 1.1 from http://www.ysbl.york.ac.uk/~ccp4mg/ The choice not to bundle this was made at the 11th hour so it is very likely some of the release documentation has not been updated. Best wishes, Graeme CCP4 Support Team From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of Victor Alves Sent: 18 December 2008 00:49 To: CCP4BB@JISCMAIL.AC.UK Subject: [ccp4bb] CCP4 6.1.0 release and CCP4MG Hi After all v6.1.0 did arrive before Christmas :-) Thank you all. Still I guess Santa, after freezing in the car park, still had to endure beeing stuck in some chimney, as a consequence of all of us who wanted to grab a fresh copy, flooding poor CCP4 server. So, after 2 days I finally "wgetted" my 1 Gigabyte Lin-RH8 copy for installation in Ubuntu. Even before installing, I browsed all the tarball and couldn't find CCP4MG? Since the documentation states it should be a separate package (like COOT), am I missing something? Also, if you choose a custom tarball, there is no option to include CCP4MG. Thank you Victor Alves > Dear All > > as we continue our journey up the A65 (towards the heart of Yorkshire) > we are pleased to announce the release of Clapham (or 6.1.0). This is > available form the usual locations > > http://www.ccp4.ac.uk/download/downloadman.php > > or > > ftp://ftp.ccp4.ac.uk/ccp4/6.1/ > > Obviously special thanks to the program authors, testers etc. Go enjoy > Please note that the downloads are large (very large if you include the > balbes database), so there may be an issue of browsers timing out > (observed for firefox so far). > > Charles Ballard > > on behalf of the CCP4 team. This message was sent using IMP, the Internet Messaging Program.
Re: [ccp4bb] iMosflm in 6.1 under OS X
Strange ... I just updated to OS 10.5.6, and fully expected to have to reinstall X11 yet again, but I still have 2.3.1 on my machine after the update. Odd that it should be inconsistent from one machine to another. Randy Read On 17 Dec 2008, at 22:54, William G. Scott wrote: Please, we all need to mention this to the Apple people. This is totally unacceptable. On Dec 17, 2008, at 2:54 PM, Engin Ozkan wrote: Yep, this happened because of the latest Mac OS 10.5.6 update. With the update, my X11 version got downgraded from 2.3.1 to 2.1.5. Engin William G. Scott wrote: Hi Engin: What do you get in response to the command otool -L /usr/X11/lib/libXdamage.1.dylib | grep "libXdamage.1.dylib" You should see /usr/X11/lib/libXdamage.1.dylib (compatibility version 3.0.0, current version 3.0.0) If you don't, update X11 here (free) to at least 2.3.1: http://xquartz.macosforge.org/trac/wiki If you do see what I do, then I suspect you need to unset the evil $DYLD_LIBRARY_PATH variable Bill On Dec 17, 2008, at 1:53 PM, Engin Ozkan wrote: By the way, is anyone experiencing the following problem with fink-installed coot? dyld: Library not loaded: /usr/X11/lib/libXdamage.1.dylib Referenced from: /sw/bin/coot Reason: Incompatible library version: coot requires version 3.0.0 or later, but libXdamage.1.dylib provides version 2.0.0 [1]Trace/BPT trapcoot Engin William G. Scott wrote: More specifically, issue fink selfupdate-cvs (or fink selfupdate-rsync) fink install itcl itk iwidgets tdom tkimg tktreectrl On Dec 17, 2008, at 7:56 AM, Andrzej Lyskowski wrote: Hi, I've just upgraded my fink distro and was wondering what else has to be done concerning configuration in order to make the iMosflm run on Mac OS. So far I'm getting the following error: Error in startup script: unknown namespace in import pattern "itcl::*" while executing "namespace import itcl::*" (file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/src/imosflm.tcl" line 91) invoked from within "source $env(IMOSFLM)" (file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl" line 111) Regards, Andrzej -- Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: + 44 1223 336500 Wellcome Trust/MRC Building Fax: + 44 1223 336827 Hills RoadE-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www- structmed.cimr.cam.ac.uk
Re: [ccp4bb] iMosflm in 6.1 under OS X
This doesn't seem to be a general phenomenon. My xquartz is still 2.3.1 after installing the latest service pack (Leopard 6). Andreas William G. Scott wrote: Please, we all need to mention this to the Apple people. This is totally unacceptable. On Dec 17, 2008, at 2:54 PM, Engin Ozkan wrote: Yep, this happened because of the latest Mac OS 10.5.6 update. With the update, my X11 version got downgraded from 2.3.1 to 2.1.5. Engin
Re: [ccp4bb] iMosflm in 6.1 under OS X
Hi Randy and Andreas, I wouldn't rely on the reported XQuartz version after updating to 10.5.6, but rather re-install the most recent version of Xquartz again, to be on the safe side. Best regards, Dirk. P.S.: This version allows to overwrite the X11 resolution with the command "defaults write org.x.X11 dpi -int 72" as an example. You can check the assumed resolution with "xdpyinfo | grep resolution" Am 18.12.2008 um 11:25 schrieb Andreas Förster: This doesn't seem to be a general phenomenon. My xquartz is still 2.3.1 after installing the latest service pack (Leopard 6). Andreas William G. Scott wrote: Please, we all need to mention this to the Apple people. This is totally unacceptable. On Dec 17, 2008, at 2:54 PM, Engin Ozkan wrote: Yep, this happened because of the latest Mac OS 10.5.6 update. With the update, my X11 version got downgraded from 2.3.1 to 2.1.5. Engin *** Dirk Kostrewa Gene Center, A 5.07 Ludwig-Maximilians-University Feodor-Lynen-Str. 25 81377 Munich Germany Phone: +49-89-2180-76845 Fax:+49-89-2180-76999 E-mail: kostr...@lmb.uni-muenchen.de ***
Re: [ccp4bb] iMosflm in 6.1 under OS X
I have a theory. Automated software updates did not update many computers correctly, macs in our lab hung at "configuring installation" and had to be restarted. This phenomenon is observed by many, and consider yourself lucky, if you haven't (Apple might have fixed it by now). http://discussions.apple.com/thread.jspa?threadID=1827638&tstart=0 http://www.pcmag.com/article2/0,2817,2337045,00.asp So, many had to download a software update from Apple's webpage for manual installation: if you have incidentally downloaded the combo update, that probably downgrades your X11. That's my theory. Engin Randy Read wrote: Strange ... I just updated to OS 10.5.6, and fully expected to have to reinstall X11 yet again, but I still have 2.3.1 on my machine after the update. Odd that it should be inconsistent from one machine to another. Randy Read On 17 Dec 2008, at 22:54, William G. Scott wrote: Please, we all need to mention this to the Apple people. This is totally unacceptable. On Dec 17, 2008, at 2:54 PM, Engin Ozkan wrote: Yep, this happened because of the latest Mac OS 10.5.6 update. With the update, my X11 version got downgraded from 2.3.1 to 2.1.5. Engin William G. Scott wrote: Hi Engin: What do you get in response to the command otool -L /usr/X11/lib/libXdamage.1.dylib | grep "libXdamage.1.dylib" You should see /usr/X11/lib/libXdamage.1.dylib (compatibility version 3.0.0, current version 3.0.0) If you don't, update X11 here (free) to at least 2.3.1: http://xquartz.macosforge.org/trac/wiki If you do see what I do, then I suspect you need to unset the evil $DYLD_LIBRARY_PATH variable Bill On Dec 17, 2008, at 1:53 PM, Engin Ozkan wrote: By the way, is anyone experiencing the following problem with fink-installed coot? dyld: Library not loaded: /usr/X11/lib/libXdamage.1.dylib Referenced from: /sw/bin/coot Reason: Incompatible library version: coot requires version 3.0.0 or later, but libXdamage.1.dylib provides version 2.0.0 [1]Trace/BPT trapcoot Engin William G. Scott wrote: More specifically, issue fink selfupdate-cvs (or fink selfupdate-rsync) fink install itcl itk iwidgets tdom tkimg tktreectrl On Dec 17, 2008, at 7:56 AM, Andrzej Lyskowski wrote: Hi, I've just upgraded my fink distro and was wondering what else has to be done concerning configuration in order to make the iMosflm run on Mac OS. So far I'm getting the following error: Error in startup script: unknown namespace in import pattern "itcl::*" while executing "namespace import itcl::*" (file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/src/imosflm.tcl" line 91) invoked from within "source $env(IMOSFLM)" (file "/sw/share/xtal/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl" line 111) Regards, Andrzej -- Randy J. Read Department of Haematology, University of Cambridge Cambridge Institute for Medical Research Tel: + 44 1223 336500 Wellcome Trust/MRC Building Fax: + 44 1223 336827 Hills RoadE-mail: rj...@cam.ac.uk Cambridge CB2 0XY, U.K. www-structmed.cimr.cam.ac.uk
[ccp4bb] FW: Refmac 5.5 vs 5.2; repost with data
Hi all, I have just installed the new CCP4I package for Windows, and refined a structure I was working on using an older version (CCP4I 6.0.2), and the refinement statistics are significantly worse when using the same input files. Under Refmac 5.2 the details were: $$ Ncyc Rfact Rfree FOM LLG rmsBOND rmsANGLE rmsCHIRAL $$ $$ 0 0.150 0.1890.886 481182.90.0111.2080.147 1 0.147 0.1880.887 480211.90.0101.1700.147 2 0.147 0.1880.887 480049.60.0101.1520.147 3 0.147 0.1880.887 479927.90.0101.1470.147 4 0.147 0.1880.887 479847.20.0101.1440.147 5 0.147 0.1880.887 479805.50.0101.1430.148 $$ Where Refmac 5.5 gives: $$ NcycRfactRfree FOM -LL -LLfree rmsBOND zBOND rmsANGL zANGL rmsCHIRAL $$ $$ 0 0.1738 0.2163 0.874465814. 25317.2 0.0106 0.439 1.208 0.519 0.147 1 0.1723 0.2158 0.875465007. 25296.4 0.0102 0.410 1.178 0.510 0.147 2 0.1716 0.2155 0.875464584. 25285.4 0.0102 0.403 1.158 0.506 0.147 3 0.1711 0.2155 0.875464297. 25278.2 0.0101 0.401 1.145 0.503 0.146 4 0.1708 0.2155 0.875464090. 25271.8 0.0101 0.399 1.137 0.501 0.146 5 0.1706 0.2155 0.876463961. 25269.1 0.0101 0.398 1.131 0.500 0.146 $$ I have been through the header of both files to check that all of the settings are the same. One thing I did notice is that the Estimated number of reflections is now 111528, where Refmac 5.2 had this value at 101968. I don't know whether this is relevant to the problem I'm seeing, but it does seem suspicious. The new Refmac has also apparently read one more reflection than the old (84317 vs 84316). Has anyone else seen this problem, and is there anything I can do to fix it (I was liking my old statistics!)? Thanks in advance, Sean
Re: [ccp4bb] FW: Refmac 5.5 vs 5.2; repost with data
Dear Sean, I have noticed this and more to the point the geometry as assessed by MOLPROBITY is much worse for the latest version of REFMAC (3.0068). I have tested a few other versions of REFMAC and the results vary quite a lot. For exactly the same run, I get the best results with an old version Refmac_5.2.0019! For my structure, exactly the same run gives the R-factors 0.218, 0.268 with 5.2.0019 (compare 0.2326 R-free 0.2915 for latest Refmac version 3.0068) and the also the best MOLPROBITY scores for (clashscore 9.03 for , compared with 22.0 for 3.0068). And the map is actually noticeably better after refining with Refmac_5.2.0019. I have been in touch with Garib about this and he is looking into it. Stephen Hi all, I have just installed the new CCP4I package for Windows, and refined a structure I was working on using an older version (CCP4I 6.0.2), and the refinement statistics are significantly worse when using the same input files. Under Refmac 5.2 the details were: $$ Ncyc Rfact Rfree FOM LLG rmsBOND rmsANGLE rmsCHIRAL $$ $$ 0 0.150 0.1890.886 481182.90.0111.2080.147 1 0.147 0.1880.887 480211.90.0101.1700.147 2 0.147 0.1880.887 480049.60.0101.1520.147 3 0.147 0.1880.887 479927.90.0101.1470.147 4 0.147 0.1880.887 479847.20.0101.1440.147 5 0.147 0.1880.887 479805.50.0101.1430.148 $$ Where Refmac 5.5 gives: $$ NcycRfactRfree FOM -LL -LLfree rmsBOND zBOND rmsANGL zANGL rmsCHIRAL $$ $$ 0 0.1738 0.2163 0.874465814. 25317.2 0.0106 0.439 1.208 0.519 0.147 1 0.1723 0.2158 0.875465007. 25296.4 0.0102 0.410 1.178 0.510 0.147 2 0.1716 0.2155 0.875464584. 25285.4 0.0102 0.403 1.158 0.506 0.147 3 0.1711 0.2155 0.875464297. 25278.2 0.0101 0.401 1.145 0.503 0.146 4 0.1708 0.2155 0.875464090. 25271.8 0.0101 0.399 1.137 0.501 0.146 5 0.1706 0.2155 0.876463961. 25269.1 0.0101 0.398 1.131 0.500 0.146 $$ I have been through the header of both files to check that all of the settings are the same. One thing I did notice is that the Estimated number of reflections is now 111528, where Refmac 5.2 had this value at 101968. I don't know whether this is relevant to the problem I'm seeing, but it does seem suspicious. The new Refmac has also apparently read one more reflection than the old (84317 vs 84316). Has anyone else seen this problem, and is there anything I can do to fix it (I was liking my old statistics!)? Thanks in advance, Sean -- ** Dr. Stephen Cusack, Head of Grenoble Outstation of EMBL Group leader in structural biology of protein-RNA complexes and viral proteins Joint appointment in EMBL Gene Expression Programme Director of CNRS-UJF-EMBL Mixed Unit (UMR 5233) for Virus Host Cell Interactions (UVHCI) ** Email: cus...@embl.fr Website: http://www.embl.fr Tel:(33) 4 76 20 7238Secretary (33) 4 76 20 7306 Fax:(33) 4 76 20 7786 or (33) 4 76 20 7199 Postal address: EMBL Grenoble Outstation, 6 Rue Jules Horowitz, BP181, 38042 Grenoble Cedex 9, France Delivery address: EMBL Grenoble Outstation, Polygone Scientifique, 6 Rue Jules Horowitz, 38042 Grenoble, France **
Re: [ccp4bb] Depositing coordinates with riding hydrogens
Jon, Riding hydrogens are *not* part of your model, they are part of the algorithm used to predict observations. Thus, the information is automatically included when you report the software used for refinement. There are definitely some (many) parameters that are never included in the deposited pdb file. Some are built into software, some simply omitted. This may be wrong, but in my humble opinion riding hydrogens are easy to recalculate and thus their inclusion constitutes redundancy. BTW, I've seen some deposited pdb files which had water molecules given with hydrogens (e.g. 1aa7 - 2.1A resolution, and look - hydrogens have zero (!) B-factors). I think the best strategy is to give up hope that every structure in the PDB will conform to your set of ideals and realize that people are free to interpret their data the way they want (of course, assuming that nearly everyone else will disagree with at least some aspect of it). Ed. On Wed, 2008-12-17 at 15:53 -0800, Jonathan Winger wrote: > Hi all- > > Just wondering what the consensus is - should a structure refined with > riding hydrogens be deposited with the coordinates for the hydrogens > included? One could argue that, since they were used in the > refinement to obtain the model and statistics reported, they should be > included in the deposited pdb file. On the other hand, the presence > of hydrogens in the pdb file might lead some to think the hydrogens > were refined against density when they really weren't. Thoughts? > > Thanks, > Jon -- 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 /
[ccp4bb] Omitted parameters
As a follow-up to the question posted by Jon Winger regarding riding hydrogens, do we all agree that the current PDB format does not allow complete reconstruction of the final stage refinement? For instance, the geometry weight factor is never reported. Second question: is it important to make sure that such reconstruction is possible? The PDB has already taken an important step in requiring experimental data deposition, so in theory I can always run my own few cycles of refinement, but we all know how often that gives you the reported Rfree. Third question: if it is important, what is the easiest way to assure it? My thinking is that the script used at the final stages of the refinement should be made available, so if you match it with the appropriate version of the software, you should in theory get the same results. Of course, with nearly 50,000 crystal structures in the PDB, the train has left the station long time ago. -- 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 /
[ccp4bb] The BNL-Biology and NSLS Course on Synchrotron Data Collection: Please Apply
We are offering RapiData 2009, the eleventh offering of our popular course: Rapid Data Collection and Structure Solving at the NSLS: A Practical Course in Macromolecular X-Ray Diffraction Measurement The course will be held 19-24 April 2009. Students could be at any level from advanced undergraduate to full professor. 48 students will be accepted; 24 will bring their own specimens for data collection. Please read the course description at http://www.px.nsls.bnl.gov/RapiData2009/. You'll see that many experts in the field will be available for lectures and tutorials, and you'll find the application materials at this site. For the seventh time we will hold a short lecture course on the fundamentals of crystallography for roughly five hours on Sunday 19 April. The body of the RapiData course really requires that students have a healthy knowledge of crystallography. For potential students who have some experience but are shaky about fundamentals, this course will help. There will be a small additional fee for the fundamentals course, to pay for Saturday night accomodations and food on Sunday morning and noon. Latin American Scientists: Several scholarships are available, from the International Union of Crystallography, to pay partial travel and subsistence costs for Latin-American students and junior faculty. Please apply for the course, and then contact R. Sweet (sw...@bnl.gov) if you are interested in applying for a scholarship. In accordance with the standards of the International Union of Crystallography, we observe the basic policy of non-discrimination, affirming the right and freedom of scientists to associate in international scientific activity without regard to such factors as citizenship, religion, creed, political stance, ethnic origin, race, colour, language, age, or gender, in accordance with the Statutes of the International Council for Science. At this course no barriers will exist beyond the application procedure that would prevent the participation of bona fide scientists. Please apply or send your students to our course, Alex Soares, Sal Sclafani, and Bob Sweet = Robert M. Sweet E-Dress: sw...@bnl.gov Group Leader, PXRR: Macromolecular ^ (that's L Crystallography Research Resource at NSLSnot 1) http://px.nsls.bnl.gov/ Biology Dept Brookhaven Nat'l Lab. Phones: Upton, NY 11973631 344 3401 (Office) U.S.A. 631 344 2741 (Facsimile) =
[ccp4bb] imosflm and ccp4 v6.1 on linux
Dear all,
I have just installed ccp4 v6.1 on a linux box running centos 5.1. Most things
seem to be working fine, but when I attempt to launch imosflm from the gui I
get the following message:
Error in startup script: can't create directory "": no such file or directory
while executing
"file mkdir $env(MOSDIR)"
invoked from within
"if { ! [file exists $env(MOSDIR)] } {
file mkdir $env(MOSDIR)
} {
if { ! [file isdirectory $env(MOSDIR)] } {
puts "stop here; the directory f..."
(file "/home/applications/CCP4-6.1/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl"
line 51)
and cannot figure out how to solve it although I am sure that it should be
fairly trivial to solve.
Any help would be greatly appreciated
best regards
Steve Carr
This e-mail and any attachments may contain
confidential, copyright and or privileged material, and are for the use of the
intended addressee only. If you are not the intended addressee or an authorised
recipient of the addressee please notify us of receipt by returning the e-mail
and do not use, copy, retain, distribute or disclose the information in or
attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not
necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments
are free from viruses and we cannot accept liability for any damage which you
may sustain as a result of software viruses which may be transmitted in or with
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and
Wales with its registered office at Diamond House, Harwell Science and
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
--
Scanned by iCritical.
Re: [ccp4bb] Depositing coordinates with riding hydrogens
On 12/18/2008 7:23 AM, Ed Pozharski wrote: Riding hydrogens are *not* part of your model, The fact that you don't see H in your fo-fc map due to limited resolution and high level of noise does not mean that H atoms are not present in actual real structure -:) There are definitely some (many) parameters that are never included in the deposited pdb file. This is true. However, whatever affects the R-factor values has to be included (there are not that many parameters). Same for geometry. Some are built into software, some simply omitted. It's ok if they are omitted BEFORE R-factors and geometry statistics calculation, otherwise it's not good. This may be wrong, but in my humble opinion riding hydrogens are easy to recalculate and thus their inclusion constitutes redundancy. Not all programs and their versions place H atoms the exact same way (using same geometry values, same rules for B-factors assignment: in some programs H inherit the B-factors of the atom it's attached to, in some it is multiplied by the factor from 1.1... to 1.5, etc. What about occupancies, especially for alternate conformations?). BTW, I've seen some deposited pdb files which had water molecules given with hydrogens (e.g. 1aa7 - 2.1A resolution, and look - hydrogens have zero (!) B-factors). There are many strange files there, even after remediation. Here is another one: http://www.rcsb.org/pdb/files/2atb.pdb Again, it's matter of just one command to remove H atoms from your PDB file, but it's not so straightforward to add them back *the exact same way they were before*. So, its much easier to keep them, rather then spend time on finding the good reasons for removing -;) Cheers, Pavel.
Re: [ccp4bb] imosflm and ccp4 v6.1 on linux
Hi Stephen,
Have you a project set up in CCP4i? Make sure that your CCP4i project
directory is set before you try to start Imosflm. When run through
CCP4i, Imosflm uses this directory to write it's output files.
You can set the project directory by clicking on the
"Directories&ProjectsDir" button in the interface.
Hope this helps.
Kind regards,
Ronan
Carr, SB (Stephen) wrote:
Dear all,
I have just installed ccp4 v6.1 on a linux box running centos 5.1. Most things
seem to be working fine, but when I attempt to launch imosflm from the gui I
get the following message:
Error in startup script: can't create directory "": no such file or directory
while executing
"file mkdir $env(MOSDIR)"
invoked from within
"if { ! [file exists $env(MOSDIR)] } {
file mkdir $env(MOSDIR)
} {
if { ! [file isdirectory $env(MOSDIR)] } {
puts "stop here; the directory f..."
(file "/home/applications/CCP4-6.1/ccp4-6.1.0/ccp4i/imosflm/imosflm.tcl"
line 51)
and cannot figure out how to solve it although I am sure that it should be
fairly trivial to solve.
Any help would be greatly appreciated
best regards
Steve Carr
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and
Wales with its registered office at Diamond House, Harwell Science and
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
Re: [ccp4bb] Depositing coordinates with riding hydrogens
Dear Ed, > Riding hydrogens are *not* part of your model, they are part of the > algorithm used to predict observations. As a diversion from PDB-ology I would point out that, according to Bayesian statistics, of which the maximum-likelihood method is a rough specialisation and approximation, "the model" and "the algorithm used to predict observations" are identical notions, if the results of that prediction are understood to be given by probability distributions over possible observations, and not just as numbers. It is just our habit of worshipping 3D graven images in the form of PDB files that make us give a peculiar meaning to the work "model": it is the whole mechanism by which that file gives rise to a prediction of structure factors (including the insertion of riding hydrogens, if desired; but also a solvent model and an error model via the sigmaa parameter) that constitutes "the model" in the Bayesian sense of the word. In any case - it was too good an opportunity to be missed to put a drop of Bayesian oil into the old crystallographic cogs. With best wishes, Gerard. -- === * * * Gerard Bricogne g...@globalphasing.com * * * * Global Phasing Ltd. * * Sheraton House, Castle Park Tel: +44-(0)1223-353033 * * Cambridge CB3 0AX, UK Fax: +44-(0)1223-366889 * * * ===
Re: [ccp4bb] Depositing coordinates with riding hydrogens
> > Riding hydrogens are *not* part of your model, > > The fact that you don't see H in your fo-fc map due to limited > resolution and high level of noise does not mean that H atoms are not > present in actual real structure -:) > Let me ask you this - are bond length restraints part of the *model*? Obviously not, they are part of refinement target. In the same way riding hydrogens are used to calculate the refinement target, but they do not increase the number of parameters of your model. So I guess my definition of the "model" excludes deduced parameters. > Not all programs and their versions place H atoms the exact same way > (using same geometry values, same rules for B-factors assignment: in > some programs H inherit the B-factors of the atom it's attached to, in > some it is multiplied by the factor from 1.1... to 1.5, etc. What > about occupancies, especially for alternate conformations?). But as I said, (if) the program and version is included in the PDB file, riding hydrogens can always be reconstructed. > Again, it's matter of just one command to remove H atoms from your PDB > file, but it's not so straightforward to add them back the exact same > way they were before. So, its much easier to keep them, rather then > spend time on finding the good reasons for removing -;) What's easy is not always right :) -- 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 /
[ccp4bb] ions vs atom scat fac
Dear All, I wonder whether someone has a quick authoritative answer (admitting a little rtfm or rtfc on my side might help) how refinement programs read and understand the charged symbols MG2+ for example and whether they properly use the corresponding scattering factor curves. Does everyone read the 77-78 for element and 79-80 for charge, as PDB format states? I recall refmac does read 13-14 for the atom symbol at least w/o problem. How about the say 2+ in 15-16? In summary the question is - where do the various refi programs read atom and charge from - if they do, do they use the proper scat curve/coeff for ions? Thx, BR PS: I am aware that the difference atom/ion affects only the low sintol region of the scattering factor curve but it is still interesting to know. - Bernhard Rupp bernhardr...@sbcglobal.net http://www.ruppweb.org/ - The hard part about playing chicken is to know when to flinch -
Re: [ccp4bb] Depositing coordinates with riding hydrogens
On 12/18/2008 8:23 AM, Ed Pozharski wrote: Riding hydrogens are *not* part of your model, The fact that you don't see H in your fo-fc map due to limited resolution and high level of noise does not mean that H atoms are not present in actual real structure -:) Let me ask you this - are bond length restraints part of the *model*? Obviously not, they are part of refinement target. In the same way riding hydrogens are used to calculate the refinement target, but they do not increase the number of parameters of your model. So I guess my definition of the "model" excludes deduced parameters. - "bond length restraints" do not contribute to the scattering and hence do not affect the R-factors, while H atoms do contribute to scattering and therefore R-factors computed from the model with or without hydrogens can be different (I spent a couple of months implementing it in PHENIX and I can say for sure that the difference is well noticeable). - the (slightly) different geometry library values for hydrogens will obviously lead to different positions for H atoms which has a great potential to yield different validation results (for example, clash scores in Molprobity). Not all programs and their versions place H atoms the exact same way (using same geometry values, same rules for B-factors assignment: in some programs H inherit the B-factors of the atom it's attached to, in some it is multiplied by the factor from 1.1... to 1.5, etc. What about occupancies, especially for alternate conformations?). But as I said, (if) the program and version is included in the PDB file, riding hydrogens can always be reconstructed. What about 50 years from now? Are you sure you will be able to dig out that xxx.zzz.aaa version of that program, install it and run? I would assume it will be much easier to take a complete model from data base. Pavel.
Re: [ccp4bb] Depositing coordinates with riding hydrogens
On Thursday 18 December 2008, Ed Pozharski wrote: > > > Riding hydrogens are *not* part of your model, > > > > The fact that you don't see H in your fo-fc map due to limited > > resolution and high level of noise does not mean that H atoms are not > > present in actual real structure -:) > > > > Let me ask you this - are bond length restraints part of the *model*? > Obviously not, they are part of refinement target. In the same way > riding hydrogens are used to calculate the refinement target, but they > do not increase the number of parameters of your model. So I guess my > definition of the "model" excludes deduced parameters. The riding-hydrogen treatment is definitely part of the model. But the number of parameters associated with it is not derived from the number of individual hydrogen atoms and their coordinates, it is limited to the number of parameters needed to describe the riding model itself. I.e. what is the C-H bond length and assigned geometry for each class of C and N atom for which hydrogens are generated. On the order of a dozen parameters total, I would guess, though I have not inspected this part of the code in refmac. > > Not all programs and their versions place H atoms the exact same way > > (using same geometry values, same rules for B-factors assignment: in > > some programs H inherit the B-factors of the atom it's attached to, in > > some it is multiplied by the factor from 1.1... to 1.5, etc. What > > about occupancies, especially for alternate conformations?). > > > But as I said, (if) the program and version is included in the PDB file, > riding hydrogens can always be reconstructed. If you can find that particular version of the program! This is relevant also for regenerating the treatment of bulk solvent, particularly if a mask is involved. The K/B values for a bulk solvent model stored in the PDB header records are not sufficient by themselves to reproduce the calculation made by a particular program. Perhaps there should be a registry of the parameters associated with each version of each refinement program, and the PDB file could refer to the appropriate parameter set by name rather than including it in-line in each individual PDB entry. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742
[ccp4bb] Applications for synchrotron beam time 2009 at EMBL Hamburg
Call for access to Synchrotron Beamline Facilities 2009 EMBL Hamburg, Germany We announce a call for synchrotron beam time applications in biological small-angle scattering (SAXS) and X-ray crystallography (PX). Up to 32 weeks of beam time will be available at the DORIS storage ring (DESY) from March 2009 to February 2010. EMBL Hamburg will operate the following beamlines: Beamline New featuresScientist responsible X33SAXS Automated and remote operation Dmitri Svergun X11PX MAR555 Flat Panel detector Paul Tucker X12PX MAD, S-SAD, fluorescence analysis Manfred Weiss X13PX Microspec, expert data collection Matthew Groves BW7A* PX High flux, multilayer opticsAndrea Schmidt BW7B* PX Automated sample changer MARVIN Santosh Panjikar *These beamlines are used as Petra-III test facilities and therefore will be only temporarily available. The deadline for submission of proposals is January 13, 2009. An external Priorities Committee will assess the proposals. Electronic beam proposal forms and a detailed description of the beamline facilities are available at www.embl-hamburg.de and www.embl-hamburg.de/facilities Access to the EMBL Hamburg high-throughput crystallisation facility is available via www.embl-hamburg.de/services/crystallisation EMBL is constructing three new beamlines for applications in biological X-ray crystallography (PX) and small-angle scattering (SAXS) at the Petra-III synchrotron storage ring, which are scheduled to be available from 2010/11. See www.embl-hamburg.de/services/petra for further information. For further information tel. +49-40-89902-110, s...@embl-hamburg.de (SAXS) b...@embl-hamburg.de (PX). Access to the EMBL Hamburg facilities will be supported by the European Commission, Research Infrastructure Action under the FP7 "ELISA (European Light Sources Activities)".
[ccp4bb] Transferring a Free R set.
Hi All, I have been in the habit of transferring my initial free R assignments to any new data sets or to isomorphous data sets such as substrate complexes. Although theoretically this is necessary to obtain a valid free R many of my colleagues maintain that this is completely unnecessary in practice. Does anyone on the list have a view on this or has anyone tested to see if it makes any difference. Alun. -- Alun R. Coker University College London Division of Medicine, Royal Free Campus Centre for Amyloidosis and Acute Phase Proteins Rowland Hill Street London NW32PF Tel: +44(0)20 7433 2764 Fax: +44(0)20 7433 2776
Re: [ccp4bb] Depositing coordinates with riding hydrogens
> - "bond length restraints" do not contribute to the scattering and > hence do not affect the R-factors, while H atoms do contribute to > scattering and therefore R-factors computed from the model with or > without hydrogens can be different (I spent a couple of months > implementing it in PHENIX and I can say for sure that the difference > is well noticeable). Excellent point. But there are many things affecting R-factors not being reported. Do I have to deposit the bulk solvent mask? I think the fundamental question is why do you need to be able to reproduce the exact R-factors. Perhaps depositing FC and PHIC along with FP and SIGFP will solve your problem? > What about 50 years from now? Are you sure you will be able to dig out > that xxx.zzz.aaa version of that program, install it and run? I would > assume it will be much easier to take a complete model from data base. Another excellent point (assuming that 50 years from now I will care about similarly old structures :)). Don't get me wrong - I think it's important that deposited structures provide complete information about the model. But why are riding hydrogens so particularly important when reporting crystallization conditions is not mandatory? Or bulk solvent parameters? Or geometry restraints you used for the custom ligand (thus it's not in the standard libraries)? I did a quick (and dirty) survey of the PDB and found that less than 2% of structures report hydrogens. I didn't distinguish riding hydrogens and high-res structures, but even if they all are riding hydrogens they still almost always are not explicitly reported. What is interesting is the breakdown by the program used CNS/XPLOR 53% SHELX 29% (these might be mostly high-res) REFMAC 12% (some should be high-res, if not all) OTHER 7% (PHENIX, MAIN, MOLLY, PROFFT, PROLSQ) So it is safe to say that riding hydrogens are almost never intentionally included in the deposited model. Given that I found over 100 structures refined in X-PLOR with riding hydrogens reported, there must be some authors reading this list who may explain their reasoning. -- 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: [ccp4bb] Depositing coordinates with riding hydrogens
On Thu, 2008-12-18 at 10:15 -0800, Ethan A Merritt wrote: > The riding-hydrogen treatment is definitely part of the model. > But the number of parameters associated with it is not derived from the > number of individual hydrogen atoms and their coordinates, it is > limited to the number of parameters needed to describe the riding model > itself. I.e. what is the C-H bond length and assigned geometry for > each class of C and N atom for which hydrogens are generated. > On the order of a dozen parameters total, I would guess, though I have > not inspected this part of the code in refmac. It is part of the model, but riding hydrogen positions are not refined (or am I missing something?). Thus, there is no formal omission. If I skip all the sidechain atoms, now that would be an omission. > If you can find that particular version of the program! > > This is relevant also for regenerating the treatment of bulk > solvent, particularly if a mask is involved. The K/B values for > a bulk solvent model stored in the PDB header records are not sufficient > by themselves to reproduce the calculation made by a particular program. > > Perhaps there should be a registry of the parameters associated with > each version of each refinement program, and the PDB file could refer > to the appropriate parameter set by name rather than including it > in-line in each individual PDB entry. Exactly! I think if this issue of incomplete deposition is to be resolved, one has to determine first why is it necessary (and it's fine if it's just a matter of principle) and what additional information is needed. -- 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: [ccp4bb] Transferring a Free R set.
Alun R. Coker schrieb: Hi All, I have been in the habit of transferring my initial free R assignments to any new data sets or to isomorphous data sets such as substrate complexes. Although theoretically this is necessary to obtain a valid free R many of my colleagues maintain that this is completely unnecessary in practice. Does anyone on the list have a view on this or has anyone tested to see if it makes any difference. Alun. Alun, I completely agree with you about the way how to treat R-free reflections. If you want to have an unbiased R-free then you need to set these reflections aside for all refinement calculations of a project, and this applies to all datasets you collect, as long as they are isomorphous. This is especially important for low resolution work where the danger of overfitting is highest. Kay smime.p7s Description: S/MIME Cryptographic Signature
Re: [ccp4bb] Transferring a Free R set.
Hi Alun, If it's necessary in theory, and it's little effort, why not do it? Even if in practise it may be not "necessary", I think not doing it is a sign of sloppy science - on a par with not sequencing your inserts to confirm absence of unwanted PCR mutations, checking by Edman degradation or mass-spec that the protein you have expressed is really the one you think it is, doing a proper map to confirm your ligand density really is that, etc etc. Am I a control freak? Perhaps, but I'd rather be a control freak than a sloppy scientist. When 2 minutes effort can potentially avert weeks of extra work in the future like discovering the difference in results is due to an unknown mutation, discovering you crystallised the wrong protein, reviewers rejecting your manuscript for not keeping the same Free R set or doubting your ligand is really there, etc, I think it is worth it... Mark Quoting "Alun R. Coker" : Hi All, I have been in the habit of transferring my initial free R assignments to any new data sets or to isomorphous data sets such as substrate complexes. Although theoretically this is necessary to obtain a valid free R many of my colleagues maintain that this is completely unnecessary in practice. Does anyone on the list have a view on this or has anyone tested to see if it makes any difference. Alun. -- Alun R. Coker University College London Division of Medicine, Royal Free Campus Centre for Amyloidosis and Acute Phase Proteins Rowland Hill Street London NW32PF Tel: +44(0)20 7433 2764 Fax: +44(0)20 7433 2776
Re: [ccp4bb] Depositing coordinates with riding hydrogens
Hi Ed,
I didn't really open a can of worms... Sorry if I did!
But there are many things affecting R-factors not
being reported. Do I have to deposit the bulk solvent mask?
Not that many and most of them are reported (at least those that may
affect the R-factor "significantly"). The model structure factor is
(well different programs may define it differently, but they normally
report the corresponding parameters) (as used in phenix.refine):
Fmodel = scale_overall * exp(-h*U_overall*ht) * (Fcalc + k_sol *
exp(-B_sol*s^2/4) * Fmask)
- anisotropic scale matrix (U_overall) is reported as "REMARK 3B11
:", ...;
- ATOM and ANISOU is enough to calculate Fcalc (the difference between
scattering tables used: it1992, wk1995 or n_gaussian will not make
visible difference) (the difference in algorithm FFT vs DIRECT used to
compute Fcalc will not, normally, make difference too);
- Bulk solvent k_sol and B_sol are reported: "REMARK 3 K_SOL" or
similar;
- Reproducing Fmask you at least need "grid_step", "solvent radius" and
"shrink truncation radius", which phenix.refine reports all:
REMARK 3 BULK SOLVENT MODELLING.
REMARK 3 METHOD USED: FLAT BULK SOLVENT MODEL
REMARK 3 SOLVENT RADIUS : 1.11
REMARK 3 SHRINKAGE RADIUS : 0.90
REMARK 3 K_SOL : 0.347
REMARK 3 B_SOL : 29.392
So I think you have all (or most of) you need to reproduce the R-factor
statistics IF PDB FILE IS COMPLETE.
I think
the fundamental question is why do you need to be able to reproduce the
exact R-factors. Perhaps depositing FC and PHIC along with FP and SIGFP
will solve your problem?
Given so little information and effort to do so, I don't see why not?
It's just a simple formula that relies on a number of simple parameters
that are easy to report and in fact they are reported in PDB file in
most of cases. If you have a few atoms model, you could use a pen and
calculator to do so -:) It's a great and simplest validation tool: if
you unable to reproduce the R-factors then something is wrong with the
1) file, 2) structure or 3) your software. However, if you explicitly
allow the R-factors to be not ("exactly") reproducible, then you
immediately loose the way to address "1)-3)".
Don't get me wrong - I think it's important that deposited structures
provide complete information about the model. But why are riding
hydrogens so particularly important when reporting crystallization
conditions is not mandatory? Or bulk solvent parameters? Or geometry
restraints you used for the custom ligand (thus it's not in the standard
libraries)?
Absolutely agree! So, let's make a tiny step forward and keep whatever
we can easily keep, and hope that in future more information will be
preserved (such as complete foot-print of restraints used and so on).
I did a quick (and dirty) survey of the PDB and found that less than 2%
of structures report hydrogens.
Well, years back people used to cut low resolution data at 5...8A until
it became clear that it's a not so good idea. Nowadays, I don't think
anyone will throw away low resolution data. Similar rationale with
hydrogens. Let's follow the progress and not look back (telling myself) -:)
All the best!
Pavel.
Re: [ccp4bb] Transferring a Free R set.
Alun, Kay is right on target; I think there is no debate about that you must use one FreeR set for all (even marginally*) isomorphous crystals. Your colleagues who are not following this practice are not doing themselves any favors. If you don't keep the same FreeR set, R & Rfree for that 2nd crystal will be almost identical --- and low!, like the R from crystal 1. Best practice is to create an initial, master FreeR set that extends well beyond your current (first crystal) resolution...crystals usually get better as time spent on a project goes on, and extending the set correctly takes some careful neuronal work (admittedly, now a bit easier with the CCP4i GUI). Dave * I've not seen any arguments for why one *shouldn't* keep the same set, even as isomorphism fades away, due, e.g., to a slightly variable unit cell. Keeping the same set does no harm; calculating the potential harm due to switching sets seems not worth the bother (though I guess one of our more theoretically-inclined contributors will see an opportunity there!). > -Original Message- > From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On > Behalf Of Kay Diederichs > Sent: Thursday, December 18, 2008 3:05 PM > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] Transferring a Free R set. > > Alun R. Coker schrieb: > > Hi All, > > > > I have been in the habit of transferring my initial free R > assignments > > to any new data sets or to isomorphous data sets such as substrate > > complexes. Although theoretically this is necessary to > obtain a valid > > free R many of my colleagues maintain that this is completely > > unnecessary in practice. Does anyone on the list have a > view on this or > > has anyone tested to see if it makes any difference. > > > > Alun. > > > > Alun, > > I completely agree with you about the way how to treat R-free > reflections. If you want to have an unbiased R-free then you > need to set > these reflections aside for all refinement calculations of a project, > and this applies to all datasets you collect, as long as they are > isomorphous. > This is especially important for low resolution work where > the danger of > overfitting is highest. > > Kay >
Re: [ccp4bb] Transferring a Free R set.
Alun, I agree completely with previously stated opinions (and your practice) that preservation of a single test set is very important for the refinement of similar structures. One complication that for spacegroups in which there is a potential axis-indexing ambiguity (e.g. certain trigonal and tetragonal cells), the same set of indices can refer to reflections with different intensities in the different datasets. That would be immediately apparent as a very high Rmerge if multiple, differently indexed dataset are merged, and may complicate transfer of a single test set among multiple, inconsistently indexed datasets for those spacegroups. Best regards, Mark Mark A. Wilson Assistant Professor Department of Biochemistry/Redox Biology Center University of Nebraska N164 Beadle Center 1901 Vine Street Lincoln, NE 68588 (402) 472-3626 mwilso...@unl.edu "Borhani, David" Sent by: CCP4 bulletin board 12/18/08 02:38 PM Please respond to "Borhani, David" To CCP4BB@JISCMAIL.AC.UK cc Subject Re: [ccp4bb] Transferring a Free R set. Alun, Kay is right on target; I think there is no debate about that you must use one FreeR set for all (even marginally*) isomorphous crystals. Your colleagues who are not following this practice are not doing themselves any favors. If you don't keep the same FreeR set, R & Rfree for that 2nd crystal will be almost identical --- and low!, like the R from crystal 1. Best practice is to create an initial, master FreeR set that extends well beyond your current (first crystal) resolution...crystals usually get better as time spent on a project goes on, and extending the set correctly takes some careful neuronal work (admittedly, now a bit easier with the CCP4i GUI). Dave * I've not seen any arguments for why one *shouldn't* keep the same set, even as isomorphism fades away, due, e.g., to a slightly variable unit cell. Keeping the same set does no harm; calculating the potential harm due to switching sets seems not worth the bother (though I guess one of our more theoretically-inclined contributors will see an opportunity there!). > -Original Message- > From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On > Behalf Of Kay Diederichs > Sent: Thursday, December 18, 2008 3:05 PM > To: CCP4BB@JISCMAIL.AC.UK > Subject: Re: [ccp4bb] Transferring a Free R set. > > Alun R. Coker schrieb: > > Hi All, > > > > I have been in the habit of transferring my initial free R > assignments > > to any new data sets or to isomorphous data sets such as substrate > > complexes. Although theoretically this is necessary to > obtain a valid > > free R many of my colleagues maintain that this is completely > > unnecessary in practice. Does anyone on the list have a > view on this or > > has anyone tested to see if it makes any difference. > > > > Alun. > > > > Alun, > > I completely agree with you about the way how to treat R-free > reflections. If you want to have an unbiased R-free then you > need to set > these reflections aside for all refinement calculations of a project, > and this applies to all datasets you collect, as long as they are > isomorphous. > This is especially important for low resolution work where > the danger of > overfitting is highest. > > Kay >
Re: [ccp4bb] Transferring a Free R set.
Alun R. Coker wrote: Hi All, I have been in the habit of transferring my initial free R assignments to any new data sets or to isomorphous data sets such as substrate complexes. Although theoretically this is necessary to obtain a valid free R many of my colleagues maintain that this is completely unnecessary in practice. Does anyone on the list have a view on this or has anyone tested to see if it makes any difference. Alun. While leaving the theory to the experts, I'll suggest a test to answer the question in an individual case. Try refining your old model against the new data, keeping the same Free set against which the model has (not) been refined. If the values of R and R-free are essentially the same, initially and perhaps through rigid body refinement, then it would have been alright to pick a new free-R set. The model is no more biased toward the working reflections (of the new dataset) than the free. The "noise" in the new dataset is completely independent from the noise in the old dataset that was being "overfit" by the working reflections. If there is a significant gap initially, with Rfree > Rwork, then there is some systematic error (difference) between the model and the data, which carries over to the new dataset, which the refinement program is partially able to fit without improving the model as measured by the free reflections. in this case it may be important to keep the same Free-R set, although if the model will undergo significant rebuilding and refinement the bias may be "shaken out" before the end. Still, the pragmatic answer would be "just do it". I don't think any reviewer will give you trouble for using the same free-R set.
Re: [ccp4bb] Transferring a Free R set.
Hi All, I suspect using a new free assignment for each data set is a fairly wide spread mistake, which would be hard to pick up by a reviewer. It would be interesting to survey the pdb for ligand bound structures which have a different free R set from their parent (isomorphous) native structures. I have heard from a colleague involved in testing refinement programs that there is a surprising number of deposited ligand structures where re-refinement shows that the ligand is built into noise. Would it be fair to say that in the case of a ligand structure, isomorphous with the native structure but where different R-free sets have been used, we cannot use the R-free to validate refinement of the ligand? My understanding is that it would be contaminated by the phases brought over with the model from the native data set, and is no longer independent, so any ligand density could just arise from over fitting. How could we test/retrieve such a situation? Will omit maps made after a round of REFMAC refinement without the ligand still have a memory of our over fitted model which would persist through to new maps? If so, would this be the case after a slow cool in CNS? Does the community still think it is valid to use a slow cool to "reset" the free R? Alun. -- Alun R. Coker University College London Division of Medicine, Royal Free Campus Centre for Amyloidosis and Acute Phase Proteins Rowland Hill Street London NW32PF Tel: +44(0)20 7433 2764 Fax: +44(0)20 7433 2776
Re: [ccp4bb] Transferring a Free R set.
Hi Alun I've never seen a soaked ligand-bound structure that's truly isomorphous with the native - simply soaking & freezing the crystal is virtually guaranteed to introduce very serious non-isomorphism, e.g. up to 5% change in one or more cell parameters. At least, we always have a MR step to solve the structure, as rigid-body refinement alone often fails to pull it in, so the R-factors always start high (> 0.4) anyway. This renders the concept of a common test set totally meaningless, since the native & ligand-bound reflections with the same indices (except maybe the low res ones) will not be in equivalent positions in reciprocal space, and in any case once it has been refined down & been through a few rounds of rebuilding any bias will very quickly disappear. Note that Rfree is a meaningful statistic only at convergence at the likelihood maximum, and at convergence all previous 'memories' of the structure are erased: bias due to 'contamination' of the test set only occurs as a result of failure to ensure convergence. Also I don't believe that any of the cases of deposited ligand structures where either there is clearly no density for the ligand, or the ligand is in the wrong place, or even the wrong ligand has been built, can be laid at the door of the test set that was used. Plain incompetence and/or wishful thinking is a much more likely explanation. So personally I think you're worrying over nothing. Just my 2p's worth. Cheers & Seasons greetings to Steve & Jon! -- Ian > -Original Message- > From: owner-ccp...@jiscmail.ac.uk > [mailto:owner-ccp...@jiscmail.ac.uk] On Behalf Of Alun R. Coker > Sent: 18 December 2008 22:45 > To: CCP4 bulletin board > Subject: Re: [ccp4bb] Transferring a Free R set. > > Hi All, > > I suspect using a new free assignment for each data set is a > fairly wide > spread mistake, which would be hard to pick up by a reviewer. > It would > be interesting to survey the pdb for ligand bound structures > which have > a different free R set from their parent (isomorphous) native > structures. I have heard from a colleague involved in testing > refinement programs that there is a surprising number of deposited > ligand structures where re-refinement shows that the ligand is built > into noise. > > Would it be fair to say that in the case of a ligand structure, > isomorphous with the native structure but where different R-free sets > have been used, we cannot use the R-free to validate > refinement of the > ligand? My understanding is that it would be contaminated by > the phases > brought over with the model from the native data set, and is > no longer > independent, so any ligand density could just arise from over > fitting. > How could we test/retrieve such a situation? Will omit maps > made after > a round of REFMAC refinement without the ligand still have a > memory of > our over fitted model which would persist through to new maps? If so, > would this be the case after a slow cool in CNS? > > Does the community still think it is valid to use a slow cool > to "reset" > the free R? > > Alun. > > -- > Alun R. Coker > University College London > Division of Medicine, Royal Free Campus > Centre for Amyloidosis and Acute Phase Proteins > Rowland Hill Street > London > NW32PF > > Tel: +44(0)20 7433 2764 > Fax: +44(0)20 7433 2776 > > Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing i.tic...@astex-therapeutics.com and destroy all copies of the message and any attached documents. Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof. Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
Re: [ccp4bb] Transferring a Free R set.
a few öre's worth from sweden ... there is a surprising number of deposited ligand structures where re-refinement shows that the ligand is built into noise. nope, not surprised at all: - http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=89 - http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=87 - http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=82 - http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=70 - http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=69 i could go on Would it be fair to say that in the case of a ligand structure, isomorphous with the native structure but where different R-free sets have been used, we cannot use the R-free to validate refinement of the ligand? My how would you use Rfree to "validate refinement of the ligand"? unless it is megarich in electrons it is not going to make much of a dent in Rfree. use other criteria to validate your ligand such as (in no particular order): - convincing fit to the density? (without needing to "explain away" things) - sensible interactions? (H-bonds, salt links, hydrophobic, no bad contacts) - good geometry and stereo-chemistry? (bonds, angles, planarity, chirality) - have we seen this conformation before? (if it occurs in the PDB already; use valligurl [http://xray.bmc.uu.se/cgi-bin/gerard/reprint_mailer.pl?pref=85] or MSD/PDBe tools) - does it explain the biology/binding data/...? understanding is that it would be contaminated by the phases brought over with the model from the native data set, and is no longer independent, so any ligand density could just arise from over fitting. sorry, but that is obviously nonsense. your unbound protein did not contain your ligand (the word "unbound" gives it away, really) so its model cannot possibly contain information that would somehow induce lovely ligand density. if anything, it should introduce model bias towards the protein because that's what you use to calculate phases. (by the by, "over-fitting" [refining more parameters than the information content of the data warrants] doesn't have much to do with this discussion, so i assumed you meant "model bias") Does the community still think it is valid to use a slow cool to "reset" the free R? far be it from me to presume to represent "the community", of course, but "yes". i suspect that some of the "holier-than-me" (sic! :-) test-set worrywarts (use refinement programs that) don't (like to) do SA --dvd disclaimer: it's late. ** Gerard J. Kleywegt [Research Fellow of the Royal Swedish Academy of Sciences] Dept. of Cell & Molecular Biology University of Uppsala Biomedical Centre Box 596 SE-751 24 Uppsala SWEDEN http://xray.bmc.uu.se/gerard/ mailto:ger...@xray.bmc.uu.se ** The opinions in this message are fictional. Any similarity to actual opinions, living or dead, is purely coincidental. **
[ccp4bb] Ordering a cDNA library
Hi All, Apologies for a non-CCP4 question. I want to clone a couple of proteins of human and mouse origin. Can anyone tell me where from I can order Human and mouse (brain/liver) cDNA library? Any suggestions are welcome. Thanks, Rajan
