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 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
