Hi Robbie: Sorry, I just saw your email now.
To make that figure, I just downloaded the automated refinement results manually from the server, loaded into coot, and took a screenshot. A couple of days later, after Gert mentioned you had since fixed it, I checked with the built-in coot interface, and, as you say, it looks fine now. In general, the problem seems to do with linking. Two examples (which both now appear to be corrected) in 3zp8 are the 5’-terminal GDP (one often gets GTP or GDP at the 5’-end of in vitro transcribed RNAs) and the modified nucleotide at the ribozyme cleavage site (2’-OMe). In some instances, these don’t get linked up the the rest of the nucleotide chain. I think the root problem is different refinement programs handle some of these things more or less gracefully by default, probably because the PDB standard (if there is one) is obscure. For example, GDP (or GTP) is often a separate cofactor, so I guess it doesn’t get linked by default. I’ve run into different subsets of this problem both with refmac and with phenix, although refmac run via coot seems to handle it gracefully. Phenix complains it can’t find the 2’-OMC cif file by default, but when pointed in the right direction, handles it, but it needs to be told to link the GDP at the 5’-terminus. PDB_REDO is a great service; certainly there is no reason to apologize for the results of an automated refinement. If it “goes wrong”, this really tells us that there is a more fundamental problem of standardization that needs to be addressed, because the automatic refinment program should run without any special knowledge, just as any interested user should be able to take the PDB and data and refine the structure for himself or herself manually without any special knowledge. All the best, Bill William G. Scott Professor, Department of Chemistry and Biochemistry and The Center for the Molecular Biology of RNA University of California at Santa Cruz Santa Cruz, California 95064 USA http://scottlab.ucsc.edu/~wgscott > On Apr 24, 2015, at 12:52 AM, Robbie Joosten <robbie_joos...@hotmail.com> > wrote: > > Hi Bill, > > I have no Idea where you got that picture, the PDB_REDO entry for 3zp8 look > pretty okay to me. You might need press F5 (or the OSX equivalent) when you > check the entry page though ;) > > Apparently something went hideously wrong with the restraint generation in > the previous run. It seems to work much better now. The modified residue > stays nicely in density. > > Problems like this are bound to occur in automated pipelines like PDB_REDO, > we cannot check all the entries by hand. So if you or anyone else finds > problems with specific entries, feedback is always welcomed. We might be able > to solve the problem and improve out software in the process. > > Cheers, > Robbie > > > > Date: Thu, 23 Apr 2015 16:15:41 -0700 > From: wgsc...@ucsc.edu > Subject: Re: [ccp4bb] 3BDN, 16.5% Ramachandran Outliers!!!!! > To: CCP4BB@JISCMAIL.AC.UK > > > > On Apr 23, 2015, at 11:43 AM, Keller, Jacob <kell...@janelia.hhmi.org> wrote: > > Is it in pdb redo? Take a look here: > http://www.cmbi.ru.nl/pdb_redo/bd/3bdn/index.html > > JPK > > Sometimes it is worth checking the pdb_redo maps, in case it does something > like it did to our 3zp8 (which has a modified nucleotide at the active site > that apparently it can’t cope with): > > <Screen Shot 2015-04-23 at 4.02.46 PM.png> > > Maybe it just hates RNA and defaults to pdb_oyvey > > Bill > > > > William G. Scott > > http://scottlab.ucsc.edu/~wgscott
