*** For details on how to be removed from this list visit the ***
*** CCP4 home page http://www.ccp4.ac.uk ***
What I usually do is:
1. calculate map using FFT (ok, really FFTBIG since 6.0) which gives
me ... probably a unit cell or a multiple of the asymmetric unit
(n*ASU).
2. extracting asymmetric unit using MAPMASK (keyword 'XYZL ASU') -
trusting it to give me n*ASU (with n mostly 1 I guess?).
3. normalise the map of n*ASU in MAPMASK ('SCAL SIGM')
4. using this normalised map in asymmetric unit in O, Coot (both can
deal with maps covering the ASU, applying symmetry on-the-fly) if
I want to look at 'one sigma' or 'three sigma' levels.
Whatever I do with this map in any program (even if I cut out a bhox
that is smaller/larger than n*ASU): as long as I do things on
map-value I can get levels in rms-units.
Obviously, if a program using these maps multiplies a user-given
cut-off value by the rms-value stored in the CCP4 map header ... I'm
doomed.
Clemens
On Thu, Oct 19, 2006 at 12:29:36PM +0100, Kevin Cowtan wrote:
> *** For details on how to be removed from this list visit the ***
> *** CCP4 home page http://www.ccp4.ac.uk ***
>
>
> Yup, I think it could probably be done.
>
> However mapmask is one of those dreadful programs which does lots of
> jobs, and so it would need considerable care to do it in such a way to
> apply the principle of least suprise in every circumstance.
>
> I'm not interested in making that sort of effort I'm afraid, even if I
> can remember enough Fortran.
>
> Kevin
>
> p.s. Does fftbig output the correct rms? If not, the whole exercise is
> pointless.
>
> P.R. Evans wrote:
> >*** For details on how to be removed from this list visit the ***
> >*** CCP4 home page http://www.ccp4.ac.uk ***
> >
> >
> >
> >Ian,
> >
> >You are right of course about calculated RMSD over an a.u., so to some
> >extent the original complaint is a bug in maprot, and extend. However,
> >even within an asymmetric unit the RMSD will depend on solvent content,
> >while the absolute density in e/A^3 does not, though it does depend on
> >the resolution and phasing quality, which affect the contrast.
> >
> >On the programs, 'extend' was superceded by mapmask because extend dealt
> >with the map section by section, which in certain pathological cases
> >could make it very slow, while mapmask does the sensible thing and loads
> >the whole map into memory. I see no reason however why mapmask & maprot
> >shouldn't do the right thing with the RMSD.
> >
> >Phil
> >
> >--On 19 October 2006 10:35:58 +0100 Ian Tickle
> ><[EMAIL PROTECTED]> wrote:
> >
> >>
> >>
> >>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.
> >>
> >>
> >>
> >
> >
> >
> >
>
--
***************************************************************
* Clemens Vonrhein, Ph.D. vonrhein AT GlobalPhasing DOT com
*
* Global Phasing Ltd.
* Sheraton House, Castle Park
* Cambridge CB3 0AX, UK
*--------------------------------------------------------------
* BUSTER Development Group (http://www.globalphasing.com)
***************************************************************
