Community Forum : Small Angle Scattering Forum
Welcome Guest   
 
 Subject : biological SAS beamline collaboration discussion.. 08/13/2019 08:37:53 AM 
Lin Yang
Posts: 2
Location
The beamline scientists from several (US) biological SAXS and SANS beamlines met at the 2019 ACA meeting, to discuss topics of common interests and potential collaboration. The meeting was originally scheduled from noon to 1:30pm. It ran much longer and we could not cover all the topics. It was agreed that we would find a forum (thanks to Kristin Stevens for making changes to the ACA forums to accommodate this) to continue the discussion and plan for future meetings.

The following scientists and expert user were present:

Richard Gillilan (CHESS, ID7A1)
Kushol Gupta (U Penn)
Michal Hammel (ALS, SIBYLS)
Jesse Hopkins (APS, BioCAT)
Byeongdu Lee (APS, )
Shuo Qian (ORNL/HFIR, BioSANS)
John Tainer (ALS/MD Anderson)
Thomas Weiss (SSRL, 4-2)
Lin Yang (NSLS-II, LiX)

Michal, Jesse, Richard, Lin and Thomas reported the status of their respective beamlines. The following topics were discussed during and after the presentations:

1. Publication standard

We are all aware of the current effort to develop publication guidelines for SAS data. There are some concerns about how to satisfy these guidelines, for instance, when multiple detectors are used for data collection at the beamline.

2. Data format

It was agreed that our users should be able to make use of the popular software (e.g. RAW), regardless of where the data were collected. Lin proposed a hdf5-based data format to include both raw and processed data from all detection channels (e.g. x-ray and HPLC detectors), as well as meta data relevant to the experiment. It was quickly rejected. Many considered raw data not necessary, and important to have the data readable by simple text editors (i.e. must be ascii, not binary). However it was recognized that hdf5 could be a suitable format for data archiving. It was agreed that exported data from the beamline should include a common set of important experimental parameters. Jesse relayed an e-mail (copied below) from our European colleagues regarding information required for SASDBD. It was agreed that all beamlines should start including this information in the data files. Jesse also expressed intention to support data from all beamlines in RAW and to offer a python API to access functionalities build into RAW.

3. HPLC data collection and processing

The issue of flow cell window fouling due to sample damage was discussed. The original agenda included a topics regarding including capabilities from different SEC-SAXS software in one place. This was not explicitly discussed. However, it sounded like RAW is starting to include new capabilities (in addition to EFA).

4. Mail-in data collection

All beamlines have some form of mail-in support, with the ALS implementation (SIBYLS beamline) most formalized/visible. NSLS-II (LiX beamline) will start a similarly scaled mail-in program soon and plan to follow the same process existing at ALS (sample container format and sample information spreadsheet). Mail-in support at other beamlines is more ad hoc.

5. Beamline control and automation

This was on the originally proposed agenda. The intention was to explore opportunities to work on common solutions. But we didn’t have time to get into it.
 Subject : Re:biological SAS beamline collaboration discussion.. 08/13/2019 08:39:17 AM 
Lin Yang
Posts: 2
Location
Here's the E-mail forwarded by Jesse regarding required information in data files:

Forwarded message
From: Clement Blanchet 
Date: Tue, Feb 19, 2019 at 10:20 AM
Subject: Request from SASBDB: Standardising SAXS beam line instrument terms used in 1D-data file headers or footers.

Dear all,

First, thank you for your interest last year at the SAS2018 conference
regarding possibility of standardising the content of data file header
and/or footer information across bioSAXS beam line facilities. The
ultimate aim is to standardise terms in keeping with Table 2 of
Trewhella et al. 2017 and to ease the SASBDB deposition process,
specifically at STEP 3 that details instrument parameters. This goal
may and/or may not be easy to achieve, opinions vary, etc, so feedback
is welcome and encouraged. However, our aim at SASBDB during 2019 is
to establish file-parsing features, with specific reference to the
upload of instrument and experimental parameters from data collected
at your beam line.

From the perspective of user uploading a dataset into SASBDB, what is
required at STEP 3 of the deposition process is a simple list of
instrument terms. However, STEP 3 is the most complicated step for
depositors to complete because many cannot locate the information, or
the information is not intuitively readable from the source (1D) data,
or is not listed/included with the 1D-data.

Below is the list of terms that are (or will be) required by SASBDB
depositors. These terms are described as a recommended set of
key-value pairs (identifier(unit):value) preferably located in either
the header or footer of a .dat file, e.g., as a simple-text or some
other easy-to-read format. The identifier(unit):values may, or may
not, be signified by a #, or some other tag (this is over to you). It
would be fantastic if the inclusion of these terms becomes a standard
feature of the 1D-data output from your beam line.

Units
What is important to include are the units for each of the
identifier(unit):values. SASBDB, by default, uses nm, oC, m, s, and ml
as the units. The requested identifiers are written using these units.
However, your beam line might use different units or measures. This
should not be a problem. What is a problem is if the units are not
specified with the identifier. For example, the following will cause
an issue:

Wavelength: 10.033 x 10^-11

Whereas:

Wavelength (m): 10.033 x 10^-11

should not.

The magnitude of the values.
With respect to the magnitude of the values, we request at least three
significant figures for all values (more are, of course, preferred).
This is to avoid the SASBDB depositors falling into the common trap of
rounding-up or rounding-down values, as is common practice. For
example, 0.0953. 0.1, and 0.124 nm are often interpreted (by many) as
equivalent X-ray wavelengths.

Nomenclature or spelling.
By default, we prefer to use common standard nomenclature symbols to
specify the unit, e.g., m, s, ms, nm, oC, mg/ml, ml/min, keV, ev.
However, if your beam line outputs ‘meters’ or ‘metres’, this should
not be a problem, although we do prefer Queen’s English (British
spelling convention).

Below are the recommended standardised .dat header- or footer
identifier(unit):value lists for batch-mode SAXS and SEC-SAXS,
respectively.

SASBDB Instrument/experiment terms for batch-mode:
Instrument: BM29
Detector: Pilatus 2M
Date: 2017-10-17
Wavelength (nm): 0.1240
(Or, alternatively: X-ray energy (keV): 10.00)
Sample-to-detector distance (m): 2.01
Exposure time/frame (s): 0.100
Sample temperature (C): 20.0

SASBDB Instrument/experiment terms for SEC-mode:
Instrument: BM29
Detector: Pilatus 2M
Column type: S75 Increase
Date: 2017-10-17
Wavelength (nm): 0.1240
(Or, alternatively: X-ray energy (keV): 10.00)
Sample-to-detector distance (m): 2.01
Exposure time/frame (s): 0.995
Sample temperature (C): 20.0
Flow rate (ml/min): 0.500
Sample injection concentration (mg/ml): 25.0
Sample injection volume (ml): 0.0750

NOTES:

Note 1: It is preferred to use the ISO time-standard format:

YYYY-mm-dd

that records the date of the measurement (not when the 2D-data were
radially/azimuthally averaged). Alternatively, an official timestamp
may also be used – also in ISO format – when the data were actually
recorded down to the points-of-minutes, e.g.,

2018-11-11 21:17:13.736

Note 2: ‘Instrument’, ‘Detector’ and ‘Column type’ are not strictly
identifier(unit):value, but are necessary because, yes, depositors
actually forget what beam line they used and how they measured the data.

Note 3: If down-stream software applications do not carry this
header/footer information forward during data processing, then so be
it - it remains the responsibility of the user to locate the
information from the original 1D data and for software developers to
deal with this information in parent file listings. However, if it
were possible to include the list of the terms described above in the
original 1D source .dat file this will already improve the situation
for many SASBDB depositors.

Note 4. It is, of course, possible for people use combinations of
data, e.g., to merge scattering data from multiple instruments from
multiple days from multiple detector positions, from multiple samples,
etc, (yes this happens). This is the user’s concern (and, in our
opinion, not a facility responsibility) and will be dealt with on a
case-by-case basis when the depositor uploads such data to SASBDB.

For the moment, the inclusion of the simple set of the above formatted
terms in the header or footer of the .dat files will go a long way in
clarifying instrument set-up parameters necessary for SASBDB data
deposition. Your thoughts, feedback and cooperation – and
implementation would be greatly appreciated and we look forward to
hearing from you in the near future. If you wish to comment publicly,
a SAXIER forum on this topic has been created under ‘Primary data
processing’ and includes example .dat files (open with Notepad or
another text editor):

https://www.saxier.org/forum/viewtopic.php?f=4&t=5540

With best regards

Cy Jeffries, Al Kikhney Clemente Borges & Clément Blanchet.
 
# of Topics per Page