-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Jan,
when you input the wrong wavelength during data processing, you rescale the Ewald sphere construction, i.e. it will result in a different unit cell and crystal to detector distance. I am not sure what you mean by 'which no program from integration to structure solution did not recognised'. How should the downstream software detect the human mistake? The wavelength you enter should of course be double checked. Nowadays this seldomly occurs because the experimental settings are usually transferred automatically and reliably between the beamline software and the processing tools. Cheers, Tim On 07/02/2015 09:27 AM, Jan Stransky wrote: > About the unit cell shrinkage: > > I have heard a lecture (I believe it was Andrea Thorn form G. > Sheldrick group on one of CCP4 meetings), where she mentioned a > mistake in X-ray wavelenght input (swaped 3rd and 4th digit), which > no program from integration to structure solution did not > recognised. It appeared in structure refinement in wrong bond > distances. > > Worth of checking. > > Jan > > On 07/01/2015 10:58 AM, Ian Tickle wrote: >> >> Paul, as an aside to this, would it be possible to have it so >> that if the relevant boxes in the "Environment Distances" menu >> are checked then H-bonds and.or bumps are automatically >> re-calculated on re-centering? Currently it's necessary to check >> off & on one of the boxes every time the view is re-centered. If >> I forget to do that it's very easy to miss bumps (and I don't >> have a great deal of faith in MP's concept of what constitutes a >> bump)! >> >> Cheers >> >> -- Ian >> >> >> On 30 June 2015 at 14:33, Ian Tickle <ianj...@gmail.com >> <mailto:ianj...@gmail.com>> wrote: >> >> >> Hello All >> >> I guess this is really a question about MolProbity (and possibly >> about autoBuster) but I assume that most Coot users will be >> using the MolProbity validation tools. >> >> I am in the process of depositing 4 structures of the same >> protein (different ligands) and I noticed that MP seems to be >> reporting an unusually large number of bumps in both the "small >> overlap" and "bad overlap" classes. In each case the resolution >> is 2 Ang., the structures have been refined by autoBuster and the >> density seems to be unequivocal, see e.g.: >> >> >> https://drive.google.com/file/d/0B4H4H-DyO60-SEQwS1k5S3RIVG8/view?usp=sharing >> >> >> >> A lot of the bumps are main-chain CHalpha to main-chain carbonyl O >> H-bonds, but there are also some CH...O side-chain H-bonds, >> again with clear density. The C...O distances are in the range >> 3.0 to 3.2 Ang., so too short for a vdW contact. The H...O >> distances are ~ 2.2 Ang. which is definitely shorter than the sum >> of the vdW radii ( H: 1.2 + O: 1.5 = 2.7). >> >> I found this survey of CH...O H-bonds but it's restricted to >> CH...O bonds at the end of helices and I see them mostly in >> sheets. >> >> http://www.mrc-lmb.cam.ac.uk/genomes/madanm/pdfs/chapter1.pdf >> >> This reports 11 examples (i.e. H-bonds, not structures) in the >> 3.0-3.2 range for the whole of the PDB (admittedly as it was in >> 2001 when the article appears to have been written). I have >> about the same number in one structure! >> >> One possibility I considered was that the unit cells had all >> somehow 'shrunk'. This can be tested with WhatCheck: however it >> only reports a very small shrinkage which translates to an error >> of ~ 0.02 Ang. in a 3 Ang. distance, which is nowhere near >> enough to explain a discrepancy of 0.5 Ang. >> >> So I guess my question is has anyone else noticed this in their >> MP dot-plots; also does anyone know what criteria does MP uses >> for testing bumps and specifically what value is it using for >> CH...O H-bonds? And of course I'd like to know whether this will >> affect my percentile ranking in the clashscore from the PDB >> validation! >> >> Cheers >> >> -- Ian >> >> > - -- - -- Dr Tim Gruene Institut fuer anorganische Chemie Tammannstr. 4 D-37077 Goettingen phone: +49 (0)551 39 22149 GPG Key ID = A46BEE1A -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iD8DBQFVlPeFUxlJ7aRr7hoRAuQXAJ4gYxRxL/BELbrDGpAxUXbUErBPgwCghcsv nEVcp0relCBO/HVt9poCnYE= =V1FJ -----END PGP SIGNATURE-----
