-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 10 -1 11 x ? ?
1 1 10 -1 10 x ? ?
1 1 10 -19 x ? ?
1 1 10 -18 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-
