Re: [ccp4bb] SHELX as model building
Since I am still developing the version of shelxe that does autotracing, it is not yet on the shelx download site, but it is available from me by email request. You will also need shelxc and shelxd. It appears to perform best (in comparison with other programs) when the phase information is weak (e.g. S-SAD or a MR solution for a small fraction of the structure, as in Arcimboldo where it starts from a couple of alpha-helices) and the resolution of the native data is about 2.5A or better. For details of how it works, see Acta Cryst. D66 (2010) 479-485 (open access). George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Mon, 1 Nov 2010, Rojan Shrestha wrote: Hello I have been using ARP/WRAP to trace the initial model. Now, I am interested to use SHELX for this purpose. Does somebody know that which package of SHELX can be used as the auto tracing of main chain? Regards, Rojan
Re: [ccp4bb] Free R with doubled cell edge
This iseasy to do Reindex 2h,k,l then the cell will double; the FreeR will stay with the reflection, and you can use those FreeRs to append to your new data in the scala/truncate GUI. All the unset ones (2h+1,k,l) willbe given new FreeRs and the old ones transferred. Eleanor in On 10/30/2010 06:08 PM, Ethan Merritt wrote: On Saturday, October 30, 2010, Boaz Shaanan wrote: Hi, I'm not sure why you want to carry the free R reflections from the small cell to the new cell. If it's the model bias vis-a vis the reflections participating the refinement that you want to get rid of you can take another route, I think. 1) Select R-free set for the new cell (paying attention to the new NCS); 2) Take the model you obtained after phaser (4 chains) and shake it to death (either in CNS by annealing or in the ccp4 shake routine or the USF equivalent). By then, your model should have got rid of the bias and you can start refinement. Gurus, have I cut any corner by suggesting this route? I think it is better to do exactly what was requested - carry forward the old Rfree to the new data set. Since the a axis is double, the Rfree of smallcell [h k l] is transferred to bigcell [2h k l] One problem with shaking things up as you describe is that if the original model was refined against higher resolution data than your new data set, you will probably never get back to the same model quality as you started with (see the ongoing discussion in another thread). And if the new data set is higher resolution, then you face the same problem in reverse. If you want to take your eventual new, higher resolution model back into the old cell you want subsequent refinement to have unbiased Rfree on that end also. Ethan Would there be any objection from referees (...)? Good luck, Boaz - Original Message - From: Kay Diederichskay.diederi...@uni-konstanz.de Date: Saturday, October 30, 2010 14:23 Subject: Re: [ccp4bb] Free R with doubled cell edge To: CCP4BB@JISCMAIL.AC.UK Hi Ed, in the new cell (long a axis), the reflections H K L are related by H=2*h K=k L=l to those of the old (short a) cell. I would expect that the R-factor of those H K L reflections with even H from the new crystal form is low (at least at low resolution) against the h k l reflections of the old crystal form. (I'd also expect that they are stronger than the odd-H reflections.) You can obtain the R-free flag for these reflections by creating a file with h k l R-free-flag from your old dataset, multiplying all h by 2 (it should be possible to do this with the CCP4 program reindex, using reindex HKL h+h, k, l as the only input line), and using that for the new data. This procedure gives you R-free flags for half of the reflections of your new dataset (those with even H). Those reflections with odd H are of course new; they are not (directly) related to any reflections of the old crystal form. You may want to randomly assign R-free flags to them; there is (I think) a task in ccp4i which takes care of partially missing R-free flags. HTH, Kay Am 20:59, schrieb Thomas Edwards: Dear BB Sages, I have a problem where I think I could very easily do the wrong thing. And I don't really want to do that... We have solved a new structure using zinc SAD phases (1 zinc in 27kD, 2 Zn/AU - Shelx, RESOLVE, ARPwARP. Cool.). In p21 30 109 65 90 105 90 at 2.5A However, we have now collected 1.9A data. In p21... 60 109 65 90 107 90 4 chains per AU instead of 2 with a doubling of a. Self rotations with the new data suggest 2 two-folds, one quite near crystallographic. It seems that the doubling of the a edge is adding an NCS two- fold that is almost crystallographic. Now, having refined against the 2.5A data to R/Rfree of about 25/30 we would like to use that model to do MR against the new high res data (We didn't collect Zn peak data for the new crystal - didn't think we'd need it.). I have done that and found 4 mols with Phaser in about 60 seconds. Still cool. So, we would like to transfer Free R flags to the new data to avoid refining against what had been labelled as Free R. My problem is - how do I do that properly? I am worried that some of the working data in the bigger cell will be correlated with Free data via the near crystallographic NCS. I clearly don't want to just copy them from the old mtz file with a0 I recall some discussion about this from years ago on the BB but can't find the right threads. Can anybody point me to the correct way to do this please - I presumably want to label with Free R flags symmetry related Free R labelled reflections from the old data that are related by the new NCS 2-fold (that is close to crystallographic) in the new data. Right?? If I have worded that correctly... I am hoping that will make sense to somebody. I think that the solutions that were recently suggested for lower vs higher symmetry in the same unit cell do not apply here. One suggestion
Re: [ccp4bb] Which version CCP4 output DFc colume in SIGMAA?
6.1.2 or later. -- Ian On Fri, Oct 29, 2010 at 7:56 PM, Hailiang Zhang zhan...@umbc.edu wrote: Hi, I remember the SIGMAA utility in some version of CCP4 can output DFC colume in the mtz file. If somebody see this colume in you SIGMAA mtz file, could you let me know which version CCP4 you are using? THanks! Best Regards, Hailiang
Re: [ccp4bb] Bug in c_truncate?
The way I do this is to use mtz2various which reads the SHELX output and (I hope) copes with its various idiosymcrasies, producing an mtz file with H k l I SigI FreeR This can then be fed to the ctruncate GUI You need - to request Ensure unique data... Copy FreeR from another mtz file Then the MTZin is the SHELX mtz conversion and the MTZ with FreeR is the same file.. I think it works although I have no data to test it. Eleanor On 10/29/2010 01:05 PM, Phil Evans wrote: The normal use of [c]truncate is to take intensities from Scala, so it wouldn't expect FreeR flags in the file. I suppose this should be added for other uses of the program Is this something that is often used? Do people import intensities into CCP4 to convert them to Fs? Phil On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote: Dear Peter, Since I did not hear that your problem is solved here my two cents. I did some tests using the ccp4i option Convert Intensities to SFs and found that here ctruncate completely ignored the FreeRflags. So my conclusion is that ctruncate does not need FreeRflags and you can use the following procedure: 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz without any special SHELX options. -- mtz 1 Careful: a FreeRflag of 1 means an unfree reflection and the free reflections have a FreeRflag of zero. 2) run ctruncate with the Convert Intensities to SFs. You will loose your FreeRflags in this stage. -- mtz 2 3) add the FreeRflags from mtz 1 to mtz 2 using cad. If you wish, I can give you a command file which will do this. It is a somewhat roundabout procedure and I hope that this bug (or feature) will be fixed by the next release of ccp4. Best, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of George M. Sheldrick Sent: Friday, October 29, 2010 12:30 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Bug in c_truncate? Tim, Although I always like to advocate XPREP, that would not work because the .sca format - most unfortunately - does not know about free R flags. George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Fri, 29 Oct 2010, Tim Gruene wrote: Hello Peter, the easiest way to overcome the problem might be to use xprep to export to sca-format and use scalepack2mtz for the conversion. That seems to be the least hasslesome way, although I am not totally sure that this procedure preserves the R-free flags set by xprep. Tim On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote: Hello Tim, Thank you for the suggestion. I have now tagged the working set as 1 and test set as 0. Unfortunately, it still gives the same error about all Rfree being the same, and only in c-truncate but not old-truncate. Perhaps I should install 6.1.3 and see if the problem still persist. Best, Peter Date: Thu, 28 Oct 2010 16:29:31 +0200 From: t...@shelx.uni-ac.gwdg.de Subject: Re: [ccp4bb] Bug in c_truncate? To: CCP4BB@JISCMAIL.AC.UK Hello Peter, I faintly rememeber a similar kind of problem, and think that if you replace -1 with 0, the problem should go away. It seemed that -1 is not an allowed flag for (some) ccp4 programs. Please let us know if this resolves the issue. Tim On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote: Dear Crystallographers, Thank you all for the emails. Below are some details of the procedures I performed leading up to the problem. The reflection file is my own data, processed in XDS and then flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i version 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 but could not find any so I assumed it is the same version of f2mtz/ctruncate/uniqueify. I used the GUI version of F2MTZ, with the settings below: - import file in SHELX format - keep existing FreeR flags - fortran format (3F4.0,2F8.3,F4.0) - added data label I other integer // FreeRflag The hkl file, in SHELX format, output by XPREP look something like this: -26 -3 1 777.48 39.19 26 -3 -1 800.83 36.31 -26 3 -1 782.67 37.97 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 Notice the test set is flagged -1 and the working set is not flagged at all. This actually lead to another error message in f2mtz about missing FreeR flags. From my understanding, the SHELX flagging convention is 1 for working and -1 for test. So I manually tagged the working set with 1 using vi: -26 -3 1 777.48 39.19 1 26 -3 -1 800.83 36.31 1 -26 3 -1 782.67 37.97 1 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 This is the file which gives me the error message: Problem with FREE column in input file. All flags apparently identical. Check input file.. Apparently, import to mtz works ok when I use old-truncate
Re: [ccp4bb] Bug in c_truncate? apologies..
I suggested mtz2various for taking SHELX input which is nonsense - it actually goes the way.. Eleanor On 10/29/2010 01:05 PM, Phil Evans wrote: The normal use of [c]truncate is to take intensities from Scala, so it wouldn't expect FreeR flags in the file. I suppose this should be added for other uses of the program Is this something that is often used? Do people import intensities into CCP4 to convert them to Fs? Phil On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote: Dear Peter, Since I did not hear that your problem is solved here my two cents. I did some tests using the ccp4i option Convert Intensities to SFs and found that here ctruncate completely ignored the FreeRflags. So my conclusion is that ctruncate does not need FreeRflags and you can use the following procedure: 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz without any special SHELX options. -- mtz 1 Careful: a FreeRflag of 1 means an unfree reflection and the free reflections have a FreeRflag of zero. 2) run ctruncate with the Convert Intensities to SFs. You will loose your FreeRflags in this stage. -- mtz 2 3) add the FreeRflags from mtz 1 to mtz 2 using cad. If you wish, I can give you a command file which will do this. It is a somewhat roundabout procedure and I hope that this bug (or feature) will be fixed by the next release of ccp4. Best, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of George M. Sheldrick Sent: Friday, October 29, 2010 12:30 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Bug in c_truncate? Tim, Although I always like to advocate XPREP, that would not work because the .sca format - most unfortunately - does not know about free R flags. George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Fri, 29 Oct 2010, Tim Gruene wrote: Hello Peter, the easiest way to overcome the problem might be to use xprep to export to sca-format and use scalepack2mtz for the conversion. That seems to be the least hasslesome way, although I am not totally sure that this procedure preserves the R-free flags set by xprep. Tim On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote: Hello Tim, Thank you for the suggestion. I have now tagged the working set as 1 and test set as 0. Unfortunately, it still gives the same error about all Rfree being the same, and only in c-truncate but not old-truncate. Perhaps I should install 6.1.3 and see if the problem still persist. Best, Peter Date: Thu, 28 Oct 2010 16:29:31 +0200 From: t...@shelx.uni-ac.gwdg.de Subject: Re: [ccp4bb] Bug in c_truncate? To: CCP4BB@JISCMAIL.AC.UK Hello Peter, I faintly rememeber a similar kind of problem, and think that if you replace -1 with 0, the problem should go away. It seemed that -1 is not an allowed flag for (some) ccp4 programs. Please let us know if this resolves the issue. Tim On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote: Dear Crystallographers, Thank you all for the emails. Below are some details of the procedures I performed leading up to the problem. The reflection file is my own data, processed in XDS and then flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i version 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 but could not find any so I assumed it is the same version of f2mtz/ctruncate/uniqueify. I used the GUI version of F2MTZ, with the settings below: - import file in SHELX format - keep existing FreeR flags - fortran format (3F4.0,2F8.3,F4.0) - added data label I other integer // FreeRflag The hkl file, in SHELX format, output by XPREP look something like this: -26 -3 1 777.48 39.19 26 -3 -1 800.83 36.31 -26 3 -1 782.67 37.97 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 Notice the test set is flagged -1 and the working set is not flagged at all. This actually lead to another error message in f2mtz about missing FreeR flags. From my understanding, the SHELX flagging convention is 1 for working and -1 for test. So I manually tagged the working set with 1 using vi: -26 -3 1 777.48 39.19 1 26 -3 -1 800.83 36.31 1 -26 3 -1 782.67 37.97 1 27 -3 1 45.722 25.711 -1 -27 3 1 -14.20 31.69 -1 This is the file which gives me the error message: Problem with FREE column in input file. All flags apparently identical. Check input file.. Apparently, import to mtz works ok when I use old-truncate instead of c-truncate. Best, Peter -- -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen phone: +49 (0)551 39 22149 GPG Key ID = A46BEE1A -- -- Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077
Re: [ccp4bb] resolution limit stuck in Refmac5
Hi Jon On 30 Oct 2010, at 00:46, Tom Huxford wrote: Hi all, I'm working with good quality relatively complete x-ray diffraction data collected to a resolution limit 2.6 Å from a crystal of a protein with a small molecule ligand bound. I ran MR from 10-4 Å and then did maximum likelihood rigid body refinement in Refmac5 against data from 50-3.5 Å. Now I would like to run restrained refinement from 50-3 Å. The reason for doing this is that, in order to minimize the divergence between R-cryst and R-free during refinement my advisor who, by the way, is forwarding this e-mail for me (and editing it so please don't bash him too mercilessly) suggested I first build in the ligand and newly positioned polypeptide loops and refine against data at a lower resolution limit before opening it up to all the available data. I personally would not first build in the ligand and refine against low res data... Assuming the ligand is what you're after, I would: (a) leave the ligand out of the time being (b) refine the model using all data (c) build the ligand in (d) refine the model using all data I'm not clear why doing restrained refinement using limited data first should help.. Apparently this has worked well for him in the past (and it has!). The problem is that I'm to the point where I'd like to extend the resolution down to 3 Å during restrained refinement but even if I set the range from 50-3 Å in the ccp4i window refinement only happens from 50-3.5 Å. If I take a step back and do the rigid body refinement from 50-3 Å and then carry out restrained refinement from 50-3 Å it works fine. Why would the limits imposed by rigid body refinement cause the subsequent restrained refinement to be stuck at the rigid body refinement's resolution limits? Are you using the original reflection file? Best Roberto Thanks for any thoughts, Jon Fleming Graduate Student Structural Biochemistry Laboratory (Huxford Lab) Department of Chemistry Biochemistry San Diego State University --- Dr. Roberto Steiner Randall Division of Cell and Molecular Biophysics New Hunt's House King's College London Guy's Campus London, SE1 1UL Phone +44 (0)20-7848-8216 Fax +44 (0)20-7848-6435 e-mail roberto.stei...@kcl.ac.uk
Re: [ccp4bb] Bug in c_truncate?
Phil Yes our processing pipeline absolutely has to be able to take in data from any internal (in-house X-ray or synchrotron) or external (PDB or collaborator's) source, including those where I, sigI and freeR flag are present. One of the first things I did was to modify truncate so it would pass through the freeR flag column. If the I/sigI are present I always strip out the F/sigF columns. So it seemed logical to run truncate as the very last step, e.g.: 1. sortmtz 2. scala Steps 1 2 only for internally collected or unmerged data. 3. refindexExternal merged data enters pipeline here: auto-re-index to reference. 4. cad Sort; put into standard a.u.; add freeR column from reference if not already present. 5. rescut My own prog for auto-determination of resolution cutoff based on shell I/sigI completeness. 6. truncate Apply resolution cutoff; if Is available convert to Fs. I always run steps 3-6 in that order. I always check that the resolution cutoff is sensible if Is are available I always run truncate to ensure it's done properly (i.e. correct cell contents are specified). I'm still using truncate because AFAICS ctruncate couldn't handle freeR flags (maybe that's fixed now, maybe not). Also truncate produces a more informative N(Z) plot which shows the expected distribution for a twinned crystal (I believe this feature has now been added to ctruncate). Cheers -- Ian On Fri, Oct 29, 2010 at 1:05 PM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: The normal use of [c]truncate is to take intensities from Scala, so it wouldn't expect FreeR flags in the file. I suppose this should be added for other uses of the program Is this something that is often used? Do people import intensities into CCP4 to convert them to Fs? Phil On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote: Dear Peter, Since I did not hear that your problem is solved here my two cents. I did some tests using the ccp4i option Convert Intensities to SFs and found that here ctruncate completely ignored the FreeRflags. So my conclusion is that ctruncate does not need FreeRflags and you can use the following procedure: 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz without any special SHELX options. -- mtz 1 Careful: a FreeRflag of 1 means an unfree reflection and the free reflections have a FreeRflag of zero. 2) run ctruncate with the Convert Intensities to SFs. You will loose your FreeRflags in this stage. -- mtz 2 3) add the FreeRflags from mtz 1 to mtz 2 using cad. If you wish, I can give you a command file which will do this. It is a somewhat roundabout procedure and I hope that this bug (or feature) will be fixed by the next release of ccp4. Best, Herman -Original Message- From: CCP4 bulletin board [mailto:ccp...@jiscmail.ac.uk] On Behalf Of George M. Sheldrick Sent: Friday, October 29, 2010 12:30 PM To: CCP4BB@JISCMAIL.AC.UK Subject: Re: [ccp4bb] Bug in c_truncate? Tim, Although I always like to advocate XPREP, that would not work because the .sca format - most unfortunately - does not know about free R flags. George Prof. George M. Sheldrick FRS Dept. Structural Chemistry, University of Goettingen, Tammannstr. 4, D37077 Goettingen, Germany Tel. +49-551-39-3021 or -3068 Fax. +49-551-39-22582 On Fri, 29 Oct 2010, Tim Gruene wrote: Hello Peter, the easiest way to overcome the problem might be to use xprep to export to sca-format and use scalepack2mtz for the conversion. That seems to be the least hasslesome way, although I am not totally sure that this procedure preserves the R-free flags set by xprep. Tim On Thu, Oct 28, 2010 at 12:48:14PM -0400, Peter Chan wrote: Hello Tim, Thank you for the suggestion. I have now tagged the working set as 1 and test set as 0. Unfortunately, it still gives the same error about all Rfree being the same, and only in c-truncate but not old-truncate. Perhaps I should install 6.1.3 and see if the problem still persist. Best, Peter Date: Thu, 28 Oct 2010 16:29:31 +0200 From: t...@shelx.uni-ac.gwdg.de Subject: Re: [ccp4bb] Bug in c_truncate? To: CCP4BB@JISCMAIL.AC.UK Hello Peter, I faintly rememeber a similar kind of problem, and think that if you replace -1 with 0, the problem should go away. It seemed that -1 is not an allowed flag for (some) ccp4 programs. Please let us know if this resolves the issue. Tim On Thu, Oct 28, 2010 at 10:21:20AM -0400, Peter Chan wrote: Dear Crystallographers, Thank you all for the emails. Below are some details of the procedures I performed leading up to the problem. The reflection file is my own data, processed in XDS and then flagging FreeR's in XPREP in thin resolution shells. I am using CCP4i version 6.1.2. I tried looking for known/resolved issues/updates in version 6.1.3 but could not find any so I assumed it is the same version of f2mtz/ctruncate/uniqueify. I used the GUI
[ccp4bb] MIFit and MIExpert v2010-10 Released
MIFit and MIExpert v2010-10 Released Faster rendering, better performance, more customizable. November 1, 2010 – The developers of MIFit and MIExpert announce the release of MIFit and MIExpert v2010-10. MIFit v2010-10 is a free, Open Source molecular graphics program for protein crystal structure determination and display. The new version of MIFit has the following features: *Easy to navigate and manipulate multiple structures and maps. *Improvements in graphics rendering performance. *Customizable jobs menu for interfacing with MIExpert or your own scripts and automated systems. *Developed with Qt 4.7 (http://qt.nokia.com). *Cross platform – supports Windows and Linux. Building on MacOS should be possible, but not yet supported. MIExpert is a suite of Python driver scripts and interfaces that manage common crystallographic structure determination tasks, primarily using the CCP4 software suite. The MIExpert interfaces are configured and exposed through MIFit. Alternatively, the driver scripts may be used as command-line components for structure solution applications. This new version of the MIFit/MIExpert system has already been used to solve many structures and is well suited for personal crystallographic computing on laptop computers. MIFit and MIExpert are available from http://code.google.com/p/mifit/ under the terms of GNU General Public License. Source code and precompiled distributions for Windows and Linux operating systems are available. MIFit and MIExpert will continue to be developed and improved. Feedback is welcomed. Bradley A. Smith, Ph.D., MIFit Project Manager John Badger, Ph.D., MIExpert Author
Re: [ccp4bb] Bug in c_truncate?
Dealing with the phases (and therefore also the Hendrickson-Lattman coefficients) on re-indexing is trivial: the phases are not changed by re-indexing because the inverse transformation must simultaneously be applied to the co-ordinates. This is because in general the re-indexing transformation is not necessarily a symmetry operator (think of P1), so you can't rely on being able to compensate for the effect on the co-ordinates by using a symmetry operator. So the effect on the phases cancels out ... unless of course your re-indexing operator inverts the hand, in which case you almost certainly don't want also to invert the hand of your co-ordinates, so in that case you must compensate by transforming the structure factors to their complex conjugates (i.e. multiply phases by -1). I guess you're thinking of the subsequent necessary transformation of the indices to the asymmetric unit, where the phases H-L coeffs do in general change (because then you are only changing the indices, not the co-ordinates); however CAD will do that transformation for you. Incidentally this is a neat illustration of the difference between a vector and a complex number. The re-indexing transformation is a transformation of the reference frame, which as long as it doesn't invert the hand, leaves the complex structure factors invariant, so they must be complex scalars (except in centric zones where they can sometimes be represented by real scalars). The indices (whether reflection or Miller!) obviously form a 3-D vector with integer elements (unless of course you're interested in diffuse scattering when they have to be reals). Either way, this is a vector because in the general case (there will be exceptions for reflections on symmetry axes) its elements change on re-indexing (that's what re-indexing means!). If the structure were in 1-D or 2-D exactly the same would apply: the 1- or 2-D elements would still in general change on transforming the reference frame so would be represented by 1- or 2-D vectors; the structure factors would still be invariant, thus illustrating the important difference between a real scalar and a 1-D vector, and between a complex scalar and a 2-D vector. Cheers --Ian On Mon, Nov 1, 2010 at 1:28 PM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: I can see we need to make sure that data can come in at any point, as Is of Fs Pointless can do automatic reindexing to a reference, and will preserve all columns from a merged file, but can't cope with phases, as I've not got round to working out appropriate phase shifts on reindexing Phil On 1 Nov 2010, at 13:17, Ian Tickle wrote: Phil Yes our processing pipeline absolutely has to be able to take in data from any internal (in-house X-ray or synchrotron) or external (PDB or collaborator's) source, including those where I, sigI and freeR flag are present. One of the first things I did was to modify truncate so it would pass through the freeR flag column. If the I/sigI are present I always strip out the F/sigF columns. So it seemed logical to run truncate as the very last step, e.g.: 1. sortmtz 2. scala Steps 1 2 only for internally collected or unmerged data. 3. refindex External merged data enters pipeline here: auto-re-index to reference. 4. cad Sort; put into standard a.u.; add freeR column from reference if not already present. 5. rescut My own prog for auto-determination of resolution cutoff based on shell I/sigI completeness. 6. truncate Apply resolution cutoff; if Is available convert to Fs. I always run steps 3-6 in that order. I always check that the resolution cutoff is sensible if Is are available I always run truncate to ensure it's done properly (i.e. correct cell contents are specified). I'm still using truncate because AFAICS ctruncate couldn't handle freeR flags (maybe that's fixed now, maybe not). Also truncate produces a more informative N(Z) plot which shows the expected distribution for a twinned crystal (I believe this feature has now been added to ctruncate). Cheers -- Ian On Fri, Oct 29, 2010 at 1:05 PM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: The normal use of [c]truncate is to take intensities from Scala, so it wouldn't expect FreeR flags in the file. I suppose this should be added for other uses of the program Is this something that is often used? Do people import intensities into CCP4 to convert them to Fs? Phil On 29 Oct 2010, at 13:01, herman.schreu...@sanofi-aventis.com wrote: Dear Peter, Since I did not hear that your problem is solved here my two cents. I did some tests using the ccp4i option Convert Intensities to SFs and found that here ctruncate completely ignored the FreeRflags. So my conclusion is that ctruncate does not need FreeRflags and you can use the following procedure: 1) convert your hkl file (including FreeRflags) into an mtz with f2mtz without any special SHELX options. -- mtz 1 Careful: a FreeRflag of 1
Re: [ccp4bb] How to get PDB of small molecule which is not available in data base..??
Hi Hussey, The structure you require might be available as a small molecule determination in the Cambridge Structural Database (CSD), if your institution doesn't already have a licence for the full database and associated software then individual structures can be requested via CCDC's website: http://www.ccdc.cam.ac.uk/products/csd/request/ Best wishes, Susan.
Re: [ccp4bb] Which version CCP4 output DFc colume in SIGMAA?
Seems 6.1.13 is the most recent version in CCP4 website... 6.1.2 or later. -- Ian On Fri, Oct 29, 2010 at 7:56 PM, Hailiang Zhang zhan...@umbc.edu wrote: Hi, I remember the SIGMAA utility in some version of CCP4 can output DFC colume in the mtz file. If somebody see this colume in you SIGMAA mtz file, could you let me know which version CCP4 you are using? THanks! Best Regards, Hailiang
Re: [ccp4bb] Bug in c_truncate?
You are right: I suppose I was thinking of arbitrary real-space transformations (eg an origin shift in P1) and also the reduction to the asymmetric unit., which are straightforward. I haven't coded the phase changes into Pointless mainly out of laziness thinking that other things were more important to spend my time on (also I've never wanted to do this myself), and I haven't thought it a particularly useful option. Phil On 1 Nov 2010, at 15:39, Ian Tickle wrote: Dealing with the phases (and therefore also the Hendrickson-Lattman coefficients) on re-indexing is trivial: the phases are not changed by re-indexing because the inverse transformation must simultaneously be applied to the co-ordinates. This is because in general the re-indexing transformation is not necessarily a symmetry operator (think of P1), so you can't rely on being able to compensate for the effect on the co-ordinates by using a symmetry operator. So the effect on the phases cancels out ... unless of course your re-indexing operator inverts the hand, in which case you almost certainly don't want also to invert the hand of your co-ordinates, so in that case you must compensate by transforming the structure factors to their complex conjugates (i.e. multiply phases by -1). I guess you're thinking of the subsequent necessary transformation of the indices to the asymmetric unit, where the phases H-L coeffs do in general change (because then you are only changing the indices, not the co-ordinates); however CAD will do that transformation for you. Incidentally this is a neat illustration of the difference between a vector and a complex number. The re-indexing transformation is a transformation of the reference frame, which as long as it doesn't invert the hand, leaves the complex structure factors invariant, so they must be complex scalars (except in centric zones where they can sometimes be represented by real scalars). The indices (whether reflection or Miller!) obviously form a 3-D vector with integer elements (unless of course you're interested in diffuse scattering when they have to be reals). Either way, this is a vector because in the general case (there will be exceptions for reflections on symmetry axes) its elements change on re-indexing (that's what re-indexing means!). If the structure were in 1-D or 2-D exactly the same would apply: the 1- or 2-D elements would still in general change on transforming the reference frame so would be represented by 1- or 2-D vectors; the structure factors would still be invariant, thus illustrating the important difference between a real scalar and a 1-D vector, and between a complex scalar and a 2-D vector. Cheers --Ian On Mon, Nov 1, 2010 at 1:28 PM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: I can see we need to make sure that data can come in at any point, as Is of Fs Pointless can do automatic reindexing to a reference, and will preserve all columns from a merged file, but can't cope with phases, as I've not got round to working out appropriate phase shifts on reindexing Phil On 1 Nov 2010, at 13:17, Ian Tickle wrote: Phil Yes our processing pipeline absolutely has to be able to take in data from any internal (in-house X-ray or synchrotron) or external (PDB or collaborator's) source, including those where I, sigI and freeR flag are present. One of the first things I did was to modify truncate so it would pass through the freeR flag column. If the I/sigI are present I always strip out the F/sigF columns. So it seemed logical to run truncate as the very last step, e.g.: 1. sortmtz 2. scala Steps 1 2 only for internally collected or unmerged data. 3. refindexExternal merged data enters pipeline here: auto-re-index to reference. 4. cad Sort; put into standard a.u.; add freeR column from reference if not already present. 5. rescut My own prog for auto-determination of resolution cutoff based on shell I/sigI completeness. 6. truncate Apply resolution cutoff; if Is available convert to Fs. I always run steps 3-6 in that order. I always check that the resolution cutoff is sensible if Is are available I always run truncate to ensure it's done properly (i.e. correct cell contents are specified). I'm still using truncate because AFAICS ctruncate couldn't handle freeR flags (maybe that's fixed now, maybe not). Also truncate produces a more informative N(Z) plot which shows the expected distribution for a twinned crystal (I believe this feature has now been added to ctruncate). Cheers -- Ian On Fri, Oct 29, 2010 at 1:05 PM, Phil Evans p...@mrc-lmb.cam.ac.uk wrote: The normal use of [c]truncate is to take intensities from Scala, so it wouldn't expect FreeR flags in the file. I suppose this should be added for other uses of the program Is this something that is often used? Do people import intensities into CCP4 to convert them to Fs? Phil
[ccp4bb] How to get the pdb from a small molecule
You need two free download programs: CHEMSKETCH and ARGUSLAB 1. Make a drawing of your target molecule with CHEMSKETCH and use Tools to both include hydrogens and to perform a 3-d optimization.Export this as a .mol file (CHEMSKETCH does not produce .pdb files). 2. Import the .mol file into ARGUSLAB and export as a .pdb file (there's nothing else to do in ARGUSLAB but it is useful for minimizing and producing various surface types eg ESP). 3. You can test the .pdb file with RASMOL and or DISCOVERY STUDIO VISUALIZER (both also free downloads and good for making nice pictures). Rex Palmer Birkbeck College, London
[ccp4bb] finding I/Sigma(I) from HKL Scalepack
Dear all, I have previously used SCALA for data reduction, and in publications and pdb depositions, reported the Mn(I/sd) output from SCALA for the whole data set and for the highest resolution shell. We now have some data that has instead been reduced using the HKL suite, and I am confused about how to find the value that would be equivalent to Mn(I/sd) from SCALA. For I/Sigma(I) I've been advised by a colleague more familiar with HKL to manually calculate from average I divided by average error (sigma). As pointed out in a previous ccp4bb thread, this would give me I/Sigma(I), which is not the same as I/Sigma(I). Two questions: (1) Is this I/Sigma(I) what is generally reported in the literature for data processed with the HKL suite? (2) Since I would also like to know the Mn(I/sd) by shell anyway so that I can compare to previous data sets, is there a way to extract this value from the scalepack log, or is there a simple reflection file analysis utility that could read the .sca or .mtz file to extract this information? Thanks for any clarifications or suggestions! Evette Evette S. Radisky, Ph.D. Assistant Professor Mayo Clinic Cancer Center Griffin Cancer Research Building, Rm 310 4500 San Pablo Road Jacksonville, FL 32224 (904) 953-6372
Re: [ccp4bb] finding I/Sigma(I) from HKL Scalepack
ctruncate outputs the table with Mn(F/sd) (which will be twice Mn(I/sd)) when it does anisotropy analysis On Mon, 2010-11-01 at 15:18 -0500, Radisky, Evette S., Ph.D. wrote: Dear all, I have previously used SCALA for data reduction, and in publications and pdb depositions, reported the Mn(I/sd) output from SCALA for the whole data set and for the highest resolution shell. We now have some data that has instead been reduced using the HKL suite, and I am confused about how to find the value that would be equivalent to Mn(I/sd) from SCALA. For I/Sigma(I) I've been advised by a colleague more familiar with HKL to manually calculate from average I divided by average error (sigma). As pointed out in a previous ccp4bb thread, this would give me I/Sigma(I), which is not the same as I/Sigma(I). Two questions: (1) Is this I/Sigma(I) what is generally reported in the literature for data processed with the HKL suite? (2) Since I would also like to know the Mn(I/sd) by shell anyway so that I can compare to previous data sets, is there a way to extract this value from the scalepack log, or is there a simple reflection file analysis utility that could read the .sca or .mtz file to extract this information? Thanks for any clarifications or suggestions! Evette Evette S. Radisky, Ph.D. Assistant Professor Mayo Clinic Cancer Center Griffin Cancer Research Building, Rm 310 4500 San Pablo Road Jacksonville, FL 32224 (904) 953-6372 -- I'd jump in myself, if I weren't so good at whistling. Julian, King of Lemurs
Re: [ccp4bb] finding I/Sigma(I) from HKL Scalepack
On 11/1/10 4:18 PM, Radisky, Evette S., Ph.D. wrote: Two questions: (1) Is this I/Sigma(I) what is generally reported in the literature for data processed with the HKL suite? Possibly. I say possibly because nobody appears to footnote their I/sigI rows in their data processing tables, so it's impossible to tell which statistic they are reporting. The editorial/proof-reading staff at journals aren't catching this ambiguity. I personally report I/sig(I) but wrote my own program to do it from the .sca files. Phil Jeffrey Princeton
[ccp4bb] Crystal lattice builder (educational)
Hi all Are there any online/offline 3D crystal lattice builders to explore symmetry relationships in the unit cell given say a space group and unit cell parameters? I need one for an educational opportunity. Thanks! F - Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder gpg --keyserver pgp.mit.edu --recv-keys 67BA8D5D 8AE2 F2F4 90F7 9640 28BC 686F 78FD 6669 67BA 8D5D
Re: [ccp4bb] finding I/Sigma(I) from HKL Scalepack
Hello Evette, I've encountered the same problem. I have a perl utility that does much of what you would like. It will run scalepack for you iteratively until the number of rejections converges, or it will parse scalepack output. The output has I/sigI by shell gleaned from the scale log with the same resolution bins used in scaling. The usage for parsing is autoscale.pl -e scale.log See if this is of any use. Best, --Paul --- On Mon, 11/1/10, Radisky, Evette S., Ph.D. radisky.eve...@mayo.edu wrote: From: Radisky, Evette S., Ph.D. radisky.eve...@mayo.edu Subject: [ccp4bb] finding I/Sigma(I) from HKL Scalepack To: CCP4BB@JISCMAIL.AC.UK Date: Monday, November 1, 2010, 4:18 PM finding I/Sigma(I) from HKL Scalepack Dear all, I have previously used SCALA for data reduction, and in publications and pdb depositions, reported the Mn(I/sd) output from SCALA for the whole data set and for the highest resolution shell. We now have some data that has instead been reduced using the HKL suite, and I am confused about how to find the value that would be equivalent to Mn(I/sd) from SCALA. For I/Sigma(I) I've been advised by a colleague more familiar with HKL to manually calculate from average I divided by average error (sigma). As pointed out in a previous ccp4bb thread, this would give me I/Sigma(I), which is not the same as I/Sigma(I). Two questions: (1) Is this I/Sigma(I) what is generally reported in the literature for data processed with the HKL suite? (2) Since I would also like to know the Mn(I/sd) by shell anyway so that I can compare to previous data sets, is there a way to extract this value from the scalepack log, or is there a simple reflection file analysis utility that could read the .sca or .mtz file to extract this information? Thanks for any clarifications or suggestions! Evette Evette S. Radisky, Ph.D. Assistant Professor Mayo Clinic Cancer Center Griffin Cancer Research Building, Rm 310 4500 San Pablo Road Jacksonville, FL 32224 (904) 953-6372 autoscale.pl Description: Perl program
[ccp4bb] What makes the difference between 2 composite omit maps?
Hi,
I want to calculate the sigmaa-weighted 2mFo-DFc composite omit map, and
tried the following 2 scripts:
(1)
./omit hklin ${f}.mtz mapout ${f}.map EOF
LABI FP=mFo FC=DFC PHI=PHIC
RESO 29.50 3.22
SCAL 2.0 -1.0
EOF
(2)
./omit hklin ${f}.mtz mapout ${f}.map EOF
LABI FP=FWT FC=FC PHI=PHIC
RESO 29.50 3.22
SCAL 1.0 0.0
EOF
The output maps are just different, and I wonder why. I am also more
concerned about which one is more appropriate for the sigmaa-weighted
2mFo-DFc composite omit map.
(mFo is what I generated from the SIGMAA output)
Thanks for any suggestions!
Best Regards, Hailiang
Re: [ccp4bb] What makes the difference between 2 composite omit maps?
sigmaa-weighted 2mFo-DFc is the _COMPOSIT_OMIT_ map. There is no point in
calculating omit map of an omit map
A brief explanation: derivation of sigmaa-weighted 2mFo-DFc formula is by
calculating Fourier coefficients of the following map:
Rescaled composite omit map, where minimal structural element (of the size
about the resolution element) is being omitted and the starting point is
the map with coefficients m*Fo*exp(i*phiCalc)
BTW, composite omit map of a map with coefficients Fo*exp(i*phiCalc) is
simply Fo-1/2Fc map that after factor of 2 scaling becomes 2Fo-Fc map
Hi,
I want to calculate the sigmaa-weighted 2mFo-DFc composite omit map, and
tried the following 2 scripts:
(1)
./omit hklin ${f}.mtz mapout ${f}.map EOF
LABI FP=mFo FC=DFC PHI=PHIC
RESO 29.50 3.22
SCAL 2.0 -1.0
EOF
(2)
./omit hklin ${f}.mtz mapout ${f}.map EOF
LABI FP=FWT FC=FC PHI=PHIC
RESO 29.50 3.22
SCAL 1.0 0.0
EOF
The output maps are just different, and I wonder why. I am also more
concerned about which one is more appropriate for the sigmaa-weighted
2mFo-DFc composite omit map.
(mFo is what I generated from the SIGMAA output)
Thanks for any suggestions!
Best Regards, Hailiang
Zbyszek Otwinowski
UT Southwestern Medical Center at Dallas
5323 Harry Hines Blvd.
Dallas, TX 75390-8816
Tel. 214-645-6385
Fax. 214-645-6353
Zbyszek Otwinowski
UT Southwestern Medical Center at Dallas
5323 Harry Hines Blvd.
Dallas, TX 75390-8816
Tel. 214-645-6385
Fax. 214-645-6353
[ccp4bb] Crystal gel band
Hi everyone, I have grown some crystals after micro-seeding starting from thin-small needles from needle-clusters. These crystals are larger in size than the needles but are comparable to the shape and don't look like salt crystals. But I cannot see the bands( its a complex) in the SDS-PAGE.I do not have a home source,handy and would like to send these to the synchrotron. Is it possible to NOT see a band of protein crystals in SDS-PAGE, if, say, the amount of protein is 1uG? Has anyone experienced such a thing (no band in gel, but crystal diffracts)? It would be nice if I get observations/suggestions. ivan
Re: [ccp4bb] Crystal gel band
Hi ivan, The detection senstivity of proteins depends on staining technique, You have not mentioned about staining, whether silver or Coomassie. The silver staining is more sensitive than coomassie, typically you can see 10-50 ng of a protein in silver staining. It does vary, however, with the glycosylation and physical properties of the protein. Shivendra On 2 November 2010 08:20, xaravich ivan xaravich.i...@gmail.com wrote: Hi everyone, I have grown some crystals after micro-seeding starting from thin-small needles from needle-clusters. These crystals are larger in size than the needles but are comparable to the shape and don't look like salt crystals. But I cannot see the bands( its a complex) in the SDS-PAGE.I do not have a home source,handy and would like to send these to the synchrotron. Is it possible to NOT see a band of protein crystals in SDS-PAGE, if, say, the amount of protein is 1uG? Has anyone experienced such a thing (no band in gel, but crystal diffracts)? It would be nice if I get observations/suggestions. ivan
Re: [ccp4bb] Crystal gel band
I have grown some crystals after micro-seeding starting from thin-small needles from needle-clusters. These crystals are larger in size than the needles but are comparable to the shape and don't look like salt crystals. But I cannot see the bands( its a complex) in the SDS-PAGE.I do not have a home source,handy and would like to send these to the synchrotron. Is it possible to NOT see a band of protein crystals in SDS-PAGE, if, say, the amount of protein is 1uG? Protein to protein variation aside (which is usually within 2X), conventional Coomassie R-250 staining gives very-easy-no-doubt detection down to ~0.1 ug. 50 ng is still visible (assuming that the gel is any good). Colloidal Coomassie G-250 (Bradford) with destaining extends the range down to 30-20 ng or 10 ng with some effort and special staining solution. Proper silver staining should easily see 1 ng. I.e., a single crystal that is a 50 um cube with 50% solvent puts you in the borderline zone of easy. Load many of them to be sure or use silver. - Dima
