Phil -
Yes, I'm one of those who's been fighting this battle for as long as I
can remember! Though actually I have to disagree with you that it's the
practice of setting the contour level as a multiple of 'sigma' (actually
the RMSD from the mean as you say) that's idiotic. There's nothing
wrong with that (and indeed it's normal statistical practice), as long
as the value of sigma stored in the map header IS correct (that really
goes without saying!). The RMSD as an estimate of the uncertainty (at
least for wFo-DFc maps anyway) is only valid provided it's calculated
using exactly an integral number of a.u.'s (e.g. 1 a.u. or half a cell
if there's at least one 2-fold, or a whole cell, i.e. N a.u.'s where N
MUST BE an integer). What's really idiotic is recalculating 'sigma'
when N is NOT an integer, which is of course usually the case when
you're cutting out a piece of map or extending it to cover the contents
of a PDB file. The uncertainty of the density values doesn't change
simply because you decide to look at a small piece of it, rather it's an
inherent property of the map.
Some time ago I updated your excellent 'extend' (but for some reason
obsoleted) program (now called 'extends') to fix this problem (mainly as
I recall because Kevin C. didn't think it was feasible to fix mapmask),
i.e. it simply copies the RMSD from the input map to the output one
instead of recalculating it every time. Additionally, it rejects
outliers in wFo-Fc maps (i.e. 'signal' as opposed to 'noise) from the
uncertainty calculation, since the uncertainty should not include these.
Here at Astex, to save disk space we store 'mini-maps' just enclosing
the binding site(s) of our protein-ligand complexes, and if you try
recalculating sigma for these based on just the volume of the cut-out
map, not surprisingly you get really idiotic values!
Sadly and rather frustratingly, extends has languished in the
'unsupported' area, so of course hardly anyone ever uses it, and a
problem which should have been fixed long ago is perpetuated.
Cheers
-- Ian
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 18, 2006 10:46 PM
To: [email protected]
Subject: Re: [ccp4bb]: maprot changing contour level?
*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
This a side effect of the idiocy of setting a contour level
as a multiple
of the so-called "sigma" level (a battle that some of us have fought &
lost for many years). This is actually the RMS deviation over
the volume
of the map box, so if this includes a larger volume of solvent the RMS
value will be smaller, ie it is a funciton of the box size!. Maps from
refinement programs (when there is a model) are on an
absolute scale in
e/A^3 and it makes sense to set contour levels in these
units, which are
independent of the box size.
Phil
>
> Hi,
> I'm attempting to use maprot to rotate a map (in order to
get the map
> covering one molecule in alignment w\ another), and noticed
that it seems
> to change the contour level of the output map (the new map
contoured at 2
> sigma seems to be equivalent to the original at 1 sigma).
>
> Based on the example for density cutting, I'm using
(cut&paste from csh
> script):
>
> maprot wrkin ${inmap} cutout ${outmap} <<eof
> mode to
> cell xtal ${cell}
> grid xtal 100 160 120
> symmetry ${symnum}
> average
> rotate polar 180.0 0.0 180.0
> translate 0 0 70.0273
> eof
>
> The same effect shows up with the identity transformation
(rotate polar 0
> 0 0 ; translate 0 0 0 ). My best guess is that it's doing
some type of
> averaging (although removing the average keyword results in
error message
> "maprot: rcards - wrong number of operaters entered").
>
> Does anyone have any suggestions as to what I'm doing wrong, or
> alternative ways of doing this (other than just looking at
the transformed
> map contoured at 2 sigma)?
>
> Thanks,
>
> Pete
>
>
> Pete Meyer
> Fu Lab
> BMCB grad student
> Cornell University
>
>
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 [EMAIL PROTECTED] 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.
