Hi Tom Welcome to the old folks club!
There are a few points in your post that I think are incredibly relevant here, and worth picking out for the casual reader - > it takes so little time to calibrate using powder diffraction Exactly! For a user collecting on a modern beamline that can collect a dataset in seconds, the time spent on this step falls below their conscious threshold, so why not do it? > It can be so hard for users to grow crystals and we want to make sure the > data quality for our users is the best possible. Again, “exactly”. I haven’t been on a data collection and processing course in the last decade where _every_ data processing developer hasn’t said something along the lines of “data collection is the _last_ experimental step (often of a long and painful process) - everything after this is computing, and can be repeated ad nauseam”. > I also remember getting really frustrated in the old days as a user with > incorrect beam position and/or detector distance in image headers and didn't > want our users to have to deal with that. This was really brought home to me when I had a dataset given to me by a user which had been collected at a well-known source (which shall remain nameless, to protect the guilty…) where _every_ useful piece of metadata in the image header was incorrect - wavelength, beam centre, crystal-to-detector distance. Fortunately, the user had noted which (fixed wavelength) beamline they had actually used, and the data were rescued (after trials of different crystal to detector distances & beam centre in the data processing). In the Mosflm coding I had (for many years) a set of “Trusted” detectors where the header values were (at the very least) good approximations to “true” - all other detector headers were considered unreliable. Of course, XDS (uniquely?) has always ignored the header information, but this has its own problems. Harry > On 16 Jul 2020, at 22:49, CARADOC-DAVIES, Tom <[email protected]> wrote: > > Hi Harry, > > I laughed when I read your question below "Or is this considered just > something that old folk do?". > > At the Australian Synchrotron MX beamlines (MX1 and MX2) we also go > old-school and collect Lanthanum hexaboride powder diffraction data during > each user setup. We collect a single 180 degree image of Lab6 at minimum > detector distance and then up to 500mm in 100mm steps. They we can analyse > the data (using automated fit2d scripts) to refine direct beam position on > the detector and the detector distance offset from reported distance. The > lab6 pin is stored in the robot dewar in a staff puck and mounting and > collecting the 6-8 images is quick (maybe 2 minutes?) as we have automated > collection and processing that runs via our user setup GUI. > This process means that values for distance and direct beam in the image > headers for each user experiment have been experimentally determined that > morning. This accuracy helps the reliability of our auto-processing > (especially for dodgy crystals). Energy is calibrated each user run or if the > LaB6 data suggests a change in "distance". > > This is probably overkill but dates from the early days when we were building > user confidence in the beamlines. I also remember getting really frustrated > in the old days as a user with incorrect beam position and/or detector > distance in image headers and didn't want our users to have to deal with > that. I also spent many hours trying to refine beamX/Y from ice rings in > imosflm from beamlines with a postit-note stuck to the side of the monitor > with cryptic beamX/Y values. > > We do get teased by some of our beamline scientist colleagues for our very > extensive beamline setup for each user (we could probably go to monthly for > some checks and weekly for others) but it takes so little time to calibrate > using powder diffraction we have just kept doing it. > > If you think that is not pedantic enough we also collect a full dataset of > cubic insulin for every setup and the user setup report shows the data > processing statistics (the users also get the raw data and auto-processing > files). If we cannot get really nice data (low Rmerge at low resolution and > good low res anomalous signal at 13keV on sulfur) on cubic insulin won't > release the beamline to users until we can investigate and fix the issue. It > is also quick as we have Eigers and collections are so fast now. > > I guess it is just part of our user support philosophy. It can be so hard for > users to grow crystals and we want to make sure the data quality for our > users is the best possible. Most users don't get the attention to detail that > goes on "under the hood" at the beamlines and this is how it should be. It is > our job to handle that stuff and success means users just expect good data > from good crystals and they get it. If you don't look for problems in the > beamlines you don’t find them. I think lot of MX experiments are viable when > a beamline has a problem (fluctuating intensity, beam position vibration, > structure in the beam etc) but some experiments are more sensitive than > others and users may think they just have bad crystals despite pretty > diffraction. > > So yes, there are people these days who collect powder data for wavelength > and beam position reference. > > Cheers, > > Tom > > > On 16/7/20, 9:26 pm, "CCP4 bulletin board on behalf of Harry Powell - > CCP4BB" <[email protected] on behalf of > [email protected]> wrote: > > Hi > > Does anyone bother collecting a powder image (e.g. Si powder) these days > so they actually have a reference that can be used to check both the > wavelength and the beam centre? Or is this considered just something that old > folk do? > > Harry > >> On 16 Jul 2020, at 12:19, Gerard DVD Kleywegt <[email protected]> wrote: >> >> There was a case a few years ago (not too many though) where a 1.6 Å >> structure had been solved using an incorrect value for the wavelength (~5% >> too low, leading to a cell that was slightly too small for its contents to >> be comfortable). It was later corrected so we could compare their validation >> statistics. Some interesting observations: >> >> - the geometry had been very tightly restrained so that didn't give a clue >> about the cell error (WhatCheck only suggested a very small change) >> >> - somewhat surprisingly (I thought) the Ramachandran plot did not improve in >> the correct model (0.3% outliers in the wwPDB validation report), and the >> sidechain rotamer outliers even got worse (from 1.5 to 2.5 %) >> >> - the map looked surprisingly good for the incorrect cell >> >> - however, RSR-Z told clearly that the map was not good enough for the >> claimed >> resolution - the model had 24% outliers! (3% in the corrected model which >> still only put it at the ~50th percentile) >> >> - another good indicator was the clashscore (went from 44 to 7) >> >> - the original model did not include an Rfree, but the R-value (>0.3 at 1.6Å >> resolution) ought to have provided a clue to the crystallographers and >> reviewers one would think >> >> It would be interesting to see what would happen if the wavelength would be >> set 5% too high. >> >> --Gerard >> >> >> >> On Thu, 16 Jul 2020, Clemens Vonrhein wrote: >> >>> Hi Robbie, >>> >>> On Wed, Jul 15, 2020 at 07:23:15PM +0000, Robbie Joosten wrote: >>>> At the same time if you have a a more relaxed approach to restraints >>>> than you might find systematic deviations in bond lengths. A test >>>> for that has been in WHAT_CHECK for decades and it actually works >>>> surprisingly well to detect cell dimension problems. >>> >>> Indeed. >>> >>>> That said, the problem is uncommon now. >>> >>> Not so sure about that: we all rely on an accurate value of the >>> energy/wavelength from the instrument/beamline - and if that is off >>> (for whatever reasons) it will result in incorrect cell dimensions and >>> a systematic deviation from the various restraints. >>> >>> This would even affect the best experiment done on the best crystal >>> ... so fairly easy to spot at the refinement stage, especially if such >>> an energy/wavelength offset is constant over a long period of time on >>> a given instrument. To spot this at the data collection stage one >>> would hope that at some point a crystal with very pronounced ice-rings >>> will be looked at properly (and the fact these are not where we expect >>> them to should cause some head-scratching). >>> >>> Cheers >>> >>> Clemens >>> >>> ######################################################################## >>> >>> To unsubscribe from the CCP4BB list, click the following link: >>> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 >>> >>> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing >>> list hosted by www.jiscmail.ac.uk, terms & conditions are available at >>> https://www.jiscmail.ac.uk/policyandsecurity/ >>> >> >> >> Best wishes, >> >> --Gerard >> >> ****************************************************************** >> Gerard J. Kleywegt >> >> http://xray.bmc.uu.se/gerard mailto:[email protected] >> ****************************************************************** >> The opinions in this message are fictional. Any similarity >> to actual opinions, living or dead, is purely coincidental. >> ****************************************************************** >> Little known gastromathematical curiosity: let "z" be the >> radius and "a" the thickness of a pizza. Then the volume >> of that pizza is equal to pi*z*z*a ! >> ****************************************************************** >> >> ######################################################################## >> >> To unsubscribe from the CCP4BB list, click the following link: >> https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 >> >> This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing >> list hosted by www.jiscmail.ac.uk, terms & conditions are available at >> https://www.jiscmail.ac.uk/policyandsecurity/ > > ######################################################################## > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 > > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing > list hosted by www.jiscmail.ac.uk, terms & conditions are available at > https://www.jiscmail.ac.uk/policyandsecurity/ > > > > ######################################################################## > > To unsubscribe from the CCP4BB list, click the following link: > https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 > > This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing > list hosted by www.jiscmail.ac.uk, terms & conditions are available at > https://www.jiscmail.ac.uk/policyandsecurity/ ######################################################################## To unsubscribe from the CCP4BB list, click the following link: https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB&A=1 This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list hosted by www.jiscmail.ac.uk, terms & conditions are available at https://www.jiscmail.ac.uk/policyandsecurity/
