Measurement workflow experiments: logbooks first

Register your samples: it's the Law! (own image, released under CC-BY license)
Register your samples: it's the Law! (own image, released under CC-BY license)

The trip to Diamond to test the USAXS instrument was a 7-day science bliss. Upon returning, however, stacks of work remained to be done. Moreover, an instrument was ready, waiting to be exploited. Strategies were needed quickly to feed the machine.

Register your samples: it's the Law! (own image, released under CC-BY license)
Register your samples: it’s the Law! (own image, released under CC-BY license)

I was fortunate to have some easy samples standing by from the TU Berlin. These allowed the development of our initial approach to measurements on this machine. The MAUS being new, it allows experimentation with new ways of doing things: we’re not stuck to a standard way of working (yet), and so it is time to rethink how we went about measurements. Here’s what we have now…

Proposal / Project sheet:

We’ve made a small excel sheet in which some details on the project can be filled in by the experimenter. A project name, contact details, and a brief description is what you’d expect to be there. We also added, however, fields for the null- and alternative hypotheses (H0 and H1, respectively).

These fields require the researcher to think about what it is they want the SAXS/WAXS measurements to disprove (as disprove is all we can do as non-mathematicians). This means thinking not only about what you expect to see, but also about what constitutes a significant difference in measurement results between samples.

This is not the usual way materials scientists work. We usually say “let’s stick the samples in and see if there is a difference”, and leave it at that. We then figured out what we meant by “a difference” later, after analysis of the results. You see that this is error-prone: if you’re looking for differences, you will probably find some. Now, however, you need to specify what you would consider to be different, and when would samples or structure be the same.

Doing this gives an estimate of the precision required. It gives me the tools to guesstimate what the best instrument configuration is for this, and how long we should measure.

Sample sheets:

Yes, the feared sample sheets are there too. We need a little bit of information on samples so we know what it is, how to store it, and what the difference is between samples. We have the support to specify a series of samples at once, though, so it’s not all that hard.

Measurement Logbook:

We have an excel sheet as a monthly log. It’s boring but powerful, and we’ve made it more powerful: this electronic logbook is automatically converted into a foolproof measurement script. That means that you fill in the planned measurements first, the locations, durations, and configurations, and this then becomes your measurements.

There are a few advantages to this. Firstly, you only need to fill in the measurement details once, removing the risks of mistyping when filling in the logbook based on the commands you typed in. It also prevents annoying the users since you minimize the number of logbooks. Secondly, you are (pretty much) required to fill in the logbook in order to start your measurements, so the logbook will always be complete. Thirdly (maybe), you will prepare your measurements as a set, not as individual measurements. This makes it easier to include the necessary extra backgrounds and double-checks.

This electronic logbook-based method is now going a bit further (maybe a bit too far): we have included motor positions for sample holders and custom slit configurations in the excel sheet as well. These get converted into the SPEC script as well, allowing us more flexibility in how we define the optimal measurement conditions.

Test measurements:

So, is it now impossible to do a “quick” measurement? No. You still can use the SPEC interface to align samples and do a single measurement. DAWN can then be used to take a quick peek at the data quality. However, it is then expected that the “real” measurement (series) is programmed into the logbook again, and converted to the measurement script.


Is it the future? At this point, it’s hard to tell. The logbook and supporting sheets will be modified regularly to adapt to the latest experimental demands. We also need to make it still easier to use at the instrument itself (where infrastructure such as a network connection is still lacking due to the building refurbishment). However, it appears to be a very powerful way of working.

And with all this, we’re now nearly ready for “friendly users” to come over and measure.

1 Comment

  1. I can’t go as far as you have with the motor positions and such, but I do need to make up a proper workflow for my SAXS. I’ll have to read through all these posts carefully.
    On another note, are you going to SAS2018?

Leave a Reply

Your email address will not be published.



This site uses Akismet to reduce spam. Learn how your comment data is processed.