Print

Print


Dear Ethan,

Alexander Schuettelkopf has sent us modified PRODRG parameter file to fix
this issue. We'll distribute it in CCP4 updates soon.
If you'd like to test it now, the prodrg.param file is here:
http://fg.oisin.rc-harwell.ac.uk/scm/loggerhead/cprodrg/trunk/download/head:/prodrg.param-20121005112644-zpoo2favxepvzj8p-80/prodrg.param

Marcin

On Thu, Jun 12, 2014 at 04:19:46PM -0700, Ethan A Merritt wrote:
> Earlier this year for the first time I got back a validation report from the
> PDB for a deposited structure that included wwPDB validation of a ligand.
> This is great stuff. I approve. I am happy.
> 
> Unfortunately the validation check reported problems with my ligand.
> This is bad. I am unhappy.  What went wrong?
> 
> A long story follows.  Skip to the end for the TL;DNR summary.
> 
> Basically I am advocating to treat errors, omissions, or inadequacies
> in the CCP4 ligand dictionaries as bugs in exactly the same sense
> as program bugs.   Report them when you find them, get them fixed
> in CCP4 updates, and down the road we will all have better structures.
> 
> ==== Long version ====
> 
> Since last year I have been happily using the integrated tools Coot,
> Jligand, cprodrg, and refmac5 to sketch a ligand, generate a dictionary,
> fit to initial difference density, and refine.  In the absence of an independent
> validation check, I thought everything was working acceptably.
> The bad grade on my wwPDB validation report [pun intended] made 
> me look into the guts of this tool chain more carefully trying to see
> what went wrong.
> 
> In short here is what happens:
> 
> - coot fires up jligand
> 
> - I sketch the compound and click "accept"
> 
> - jligand creates a file prodrg-in.mdl that contains only
>   atom type, connectivity, single/double bond flag
> 
> - cprodrg takes this and assigns each atom a more complete
>   chemical label, for example
> 	O  15.9994      CARBONYL OXYGEN (C=O)
> 	CH2  12.011       ALIPHATIC CH2-GROUP
> 	NR  14.0067      AROMATIC NITROGEN
> 
> - cprodrg then categorizes each bond by the assigned types of
>   the two bonded atoms, and similarly categorizes each bond angle
>   by the assigned types of its three constituent atoms.
> 
> So far so good.  Now comes the problematic part.
> 
> - cprodrg tries to find a target geometry (ideal bond length or angle)
>   for each category by matching against the contents of the file
>   .../Prodrg/param/ff/default
>  If an exact match is not found, it falls through to ... well I'm not
>  sure exactly what the rule is for falling through.  This is the part
>  that goes wrong.
> 
> The content of this default parameter file is rather impoverished.
> My ligand contained a pyrazole  (5-membered ring with 2 adjacent
> nitrogens).  The nitrogens were assigned a category 
> 	NR5  14.0067      NITROGEN (5-RING)
> But the default file contains no bond or angle entries for this
> atom type, so it "falls through" to the only N-N bond it does contain
> 	NSP - NSP  target length 1.12Å
> That's miles off, or at any rate more than 1/3 Å  off, the expected
> length of 1.396Å tabulated in the Mogul database for a pyrazole.
> (The wwPDB report listed a target of 1.37Å).
> 
> I don't expect perfection, but target errors of more than 0.3Å in
> bond length are large compared to the expected accuracy of even
> a modest resolution protein structure.  No wonder the wwPDB 
> validation report flagged it as a 13 sigma outlier in the refined
> structure.  
> 
> ==== TL;DNR version ====
> 
> The $CCP4/share/prodrg/prodrg.param file does not contain
> target values for many bond types that are correctly identified
> by prodrg itself.
> 
> Adding a single line handling NR5-NR5 bonds to the source file 
> ccp4-6.4.0/src/Prodrg/param/ff/default
> yields a significant improvement in my refined protein structure.
> Even the R/Rfree are improved, which surprised me.
> These were identical runs except for the regenerated ligand dictionary.
> 
> Would it be appropriate to report this as a bug?    I think so.
> 
> Where should I report it?

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom