*** For details on how to be removed from this list visit the *** *** CCP4 home page http://www.ccp4.ac.uk ***
Phil, I think we're in total agreement! You'll notice I hedged my reply by saying I was talking specifically about difference maps where I think the issue of solvent content doesn't arise, i.e. one is only concerned with distinguishing 'signal' from 'noise'. The 'sigma' for a 2mFo-DFc map as everyone knows is pretty meaningless and, as you rightly point out, totally dependent on the solvent content (because it's all 'signal', so there are virtually no regions of pure 'noise' which would allow you to estimate the uncertainty properly). In fact a better estimate of sigma for a 2mFo-DFc map would probably be twice the sigma for the mFo-DFc map computed using the same data & resolution cutoffs. This would make it independent of solvent content, but it would of course require a change in the 'typical' sigma level needed for a 2mFo-DFc map (i.e. around 1) that everyone has become used to! -- Ian > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of P.R. Evans > Sent: Thursday, October 19, 2006 11:49 AM > 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 *** > > > > 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. > > > > > > > > > > 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.
