Re: [ccp4bb] finding from HKL Scalepack
Dear Evette, You can still get this analysis with Scala even after scaling with scalepack. If you output the measurements unmerged (no merge original index) you can convert them to MTZ using pointless, then remerge the data as follows: scala hkiin from_pointless.mtz hklout merged.mtz << eof run 1 all scales constant sdcorrection noadjust norefine both 1 0 0 cycles 0 eof (pointless -c scain ... - you will also need to assign the cell and symmetry) This will just remerge the measurements and give you the usual merging analysis from Scala. Very useful. Same trick also works with data from XDS/XSCALE. Best wishes, Graeme On 1 November 2010 20:18, 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 /, which is not the same as . > > Two questions: > > (1) Is this / 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] 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
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 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 >
[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] 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 < 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 < 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] 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 <
Re: [ccp4bb] finding 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 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. wrote: From: Radisky, Evette S., Ph.D. Subject: [ccp4bb] finding from HKL Scalepack To: CCP4BB@JISCMAIL.AC.UK Date: Monday, November 1, 2010, 4:18 PM finding 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 /, which is not the same as . Two questions: (1) Is this / 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] 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 from HKL Scalepack
On 11/1/10 4:18 PM, Radisky, Evette S., Ph.D. wrote: Two questions: (1) Is this / 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 but wrote my own program to do it from the .sca files. Phil Jeffrey Princeton
Re: [ccp4bb] finding 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 /, which is > not the same as . > > Two questions: > > (1) Is this / 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
[ccp4bb] finding 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 /, which is not the same as . Two questions: (1) Is this / 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
[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
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 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 & 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 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 u
Re: [ccp4bb] Which version CCP4 output DFc colume in SIGMAA?
Correct, CCP4 6.1.13 is also good. I notice that the SIGMAA documentation in 6.1.13 isn't up-to-date & doesn't mention 'DFC'; my apologies for that omission. However if you run it, the log file says something like: Option PARTIAL -- map coefficients: (a) Fourier map:2mFo-DFc exp(i phic) (b) Difference map: 2(mFo-DFc) exp(i phic) HKLOUT contains columns H K L ... FWT DELFWT DFC WCMB -- Ian On Mon, Nov 1, 2010 at 4:03 PM, wrote: > You mean CCP4 version 6.1.2 or later right? > > Thanks! > > Hailiang > >> 6.1.2 or later. >> >> -- Ian >> >> On Fri, Oct 29, 2010 at 7:56 PM, Hailiang Zhang 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] 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 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] 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] 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 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 & 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 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 (includin
[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?
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 & 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 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
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? 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 T
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
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 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] 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 Diederichs 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 has been to do the MolRep
Re: [ccp4bb] resolution limit stuck in Refmac5
I guess you are using as input mtz the output mtz from the previous cycle? This will be limited to the requested previous resolution.. it is good practice to always use as input the full data - eg mystuff-scala.mtz output from the scala/ctruncate step.. If the input file has the full resolution then your requested limits should be respected.. Unlike your supervisor I would probably have run the rigid body refinement against limited data then gone straight to using thefull resolution available - restrained refinement of B factors works better the higher the resolution, and provides a very useful way of smudging out errors. Wrong bits often have B factors which go through the roof, and it is then very obvious in the maps But there are many ways to kill a goose, and ditto for refinement strategy.. Eleanor On 10/30/2010 01:46 AM, 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. 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? Thanks for any thoughts, Jon Fleming Graduate Student Structural Biochemistry Laboratory (Huxford Lab) Department of Chemistry & Biochemistry San Diego State University
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 > >
