-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >
> Hi Nick, Robbie, > > I encountered the same problem. This is not a bug but the way the data was deposited. > They have deposited intensities. What I did to be able to look at the maps: > Retrieve the "structure factor" file, which in fact contains intensities > Run it through Truncate to get Fs Remove the ligand from the PDB > REFMAC still refused to read in the new mtz file, for a reason I could not find. But BUSTER took it without problem > Then look at the electron density in COOT... if the ligand was properly present, it should come clearly in the difference density > > > Magali Mathieu Head of SB-X2S Sanofi LGCR - SDI Centre de Recherche > de Vitry/Alfortville TÉL. : +33 (0) 1.58.93.39.90 - FAX : +33 (0) 1.58.93.80.63 13, quai Jules Guesde – BP 14 – 94403 Vitry-sur-Seine Cedex France > Dear Prof Mathieu, I don't think you have the right answer for these entries. Many entries in the PDB have intensities and the maps from the EDS are fine. I think the real problem lies at the end of the deposited mmCIFs. When you look there you see that each of these two entries have about 30,000 lines that look like 1 1 1 0 -1 11 x ? ? 1 1 1 0 -1 10 x ? ? 1 1 1 0 -1 9 x ? ? 1 1 1 0 -1 8 x ? ? These lines are odd because the "x" says that the reflection has a weak or unreliably measured intensity while the "?" says that the intensity could be anything. This is sort of an internal contradiction and makes the intent of the CIFs creator a little unclear. More damning is the observation that the mtz that Coot downloads from the EDS contains values for the Fourier coefficients for these very reflections! While their amplitudes are small, with 30,000 of them, they add up. I have been waiting for my contact at the EDS to return to the Internet to get a definitive word but he is still disconnected from the world. Your post makes it clear that Refmac is having problems with these reflections while Buster ignores them. I have done the map calculation in TNT w/o these reflections (of course) and the maps look fine. I'm guessing that PDB_REDO junks these reflections before its Refmac refinement and avoids the issue. Dale Tronrud On 9/1/2014 2:00 AM, Magali Mathieu wrote: > > > Please consider the environment before printing this email! > > > -----Message d'origine----- De : CCP4 bulletin board > [mailto:CCP4BB@JISCMAIL.AC.UK] De la part de Robbie Joosten Envoyé > : vendredi 29 août 2014 15:48 À : CCP4BB@JISCMAIL.AC.UK Objet : Re: > [ccp4bb] KRAS maps > > Hi Nick, > > Not sure what happened here, it seems like a bug in this EDS entry. > You can try PDB_REDO for maps. In recent versions of COOT (version > 0.8*) the button for getting maps and a model is just under that > for EDS. There is a plugin for older versions of COOT. They look > okay, but the model has changed (on purpose). > > If you prefer looking at maps for an unmodified model you can > download the mtz files here: > http://www.cmbi.ru.nl/pdb_redo/lu/4luc/4luc_0cyc.mtz.gz > http://www.cmbi.ru.nl/pdb_redo/lv/4lv6/4lv6_0cyc.mtz.gz > > Cheers, Robbie > > > >> -----Original Message----- From: CCP4 bulletin board >> [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of Nicholas Larsen Sent: >> Friday, August 29, 2014 15:36 To: CCP4BB@JISCMAIL.AC.UK Subject: >> [ccp4bb] KRAS maps >> >> Dear All, I frequently use the Coot feature "Fetch PDB and MAP >> using EDS..." with great success when peer reviewing literature >> reports. However, when I try this for the recent KRAS structures >> deposited by Kevan Shokat and Jim Wells (Nature 2013), the Coot >> generated maps are garbage, although the resolution is better >> than 1.5 A. Does anyone have an explanation? I also checked >> with one kind colleague at another institute and she confirmed my >> problem using Linux platform (I am using Windows). >> >> See PDBs, 4LUC and 4LV6, for example. >> >> Cheers, Nick >> >> >> >> [This e-mail message may contain privileged, confidential and/or >> proprietary information of H3 Biomedicine. If you believe that >> it has been sent to you in error, please contact the sender >> immediately and delete the message including any attachments, >> without copying, using, or distributing any of the information >> contained therein. This e-mail message should not be interpreted >> to include a digital or electronic signature that can be used to >> authenticate an agreement, contract or other legal document, nor >> to reflect an intention to be bound to any legally-binding >> agreement or contract.] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iEYEARECAAYFAlQEtugACgkQU5C0gGfAG12ERQCfVwu83cItNGOpTPF3q0jHDuHy 3MoAmwbb6/BTjnUi12BrsXBTHaQt9RcH =RWw6 -----END PGP SIGNATURE-----
