Can anyone explain the rationale for treating the test set reflections
as 'unobserved' for the maps, even though they have perfectly good
observed Fo values? This doesn't make a great deal of sense to me!
Looking at the mtzdump output for the MTZ file output by Refmac, I
indeed note that for these reflections, the amplitude for the weighted
difference Fourier (i.e. column labelled DELFWT) is set to zero, and the
amplitude for the weighted Fourier (i.e. column labelled FWT) is set to
D.Fc (which is at least logical since if we set Fo such that mFo-DFc = 0
then mFo = DFc and so 2mFo-DFc = DFc). But it would seem more sensible
to compute the coefficients based on the observed Fo since we have them!
My rationale for this would be: in as much as the maps obtained from a
refinement with the test set excluded do not reflect the 'final' density
for publication, which I think is generally agreed should be obtained
from a final refinement using all data (working + test set), the maps
using the observed mFo instead of DFc for the test set would reflect the
true differences between this and the final maps, i.e. they would
indicate the true effect of omitting the test set.
I accept there is a practical problem here in that the sigmaA values
which are needed to compute the map coefficients are only unbiased if
computed from the test set, but a way around this would be to carry
forward the sigmaA values from the penultimate refinement excluding the
test set and use those in the final refinement using all data. This is
not a perfect solution, but it's better than nothing.
-- Ian
> -----Original Message-----
> From: [log in to unmask]
> [mailto:[log in to unmask]] On Behalf Of George M. Sheldrick
> Sent: 12 March 2008 16:01
> To: Simon Kolstoe
> Cc: [log in to unmask]
> Subject: Re: [ccp4bb] Missing reflections
>
> All these programs only refine against reflections that were actually
> measured. REFMAC, but not SHELXL, provides the 'Sigma-A' weight
> coefficients for Coot to use DFc instead of 2mFo-DFc for the
> reflections
> for which Fo is not known (or is reserved for the free R) to
> calculate a
> map. This will in general improve the appearence of the map
> at the cost
> of introducing a little model bias. As far as I know these
> 'unobserved'
> reflections are not used in calculating the difference map. CNS is
> probably like SHELXL, I'm not sure what phenix.refine does.
>
> 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-2582
>
>
> On Wed, 12 Mar 2008, Simon Kolstoe wrote:
>
> > Dear CCP4bb,
> >
> > I was looking through the REFMAC manual today and found the
> following advice:
> >
> > "Completing the data to include all possible hkls. Should
> do this after data
> > reduction, and certainly before using REFMAC. This is now
> done with the
> > uniqueify script. It is best done using CCP4i."
> >
> > http://www.ccp4.ac.uk/dist/html/refmac5/usage/examples.html#exam0
> >
> > Is it a good idea to always run uniqueify on data before
> running REFMAC - what
> > about other refinement programs such as SHELX, CNS or phenix.refine?
> >
> > Simon
> >
>
>
Disclaimer
This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [log in to unmask] and destroy all copies of the message and any attached documents.
Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof.
Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
|