The purpose of the Global Phasing (GPhL) Abstract Beamline Interface is to support the development and execution of data collection strategies for Macromolecular Crystallography (MX) at synchrotron beamlines, in particular where those strategies are generated by third-party applications outside the Beamline Control System (BCS). GPhL is currently developing software that designs strategies according to exacting scientific criteria. In order for that software to be transferable, and its output executable, a specification is required that bridges the gap between the strategy design process and the BCS: such is the role of the Abstract Beamline Interface. The intention is that BCSs that implement this Interface will be able to support the software that GPhL is developing.
|
ℹ️
|
More information
The "Wiki" link above will take you to a set of pages that provide more information and context relevant to the Abstract Beamline Interface. If you have any questions, corrections or suggestions, please either open an issue
using the "Issues" link above, or e-mail us at
|
The ever-increasing speed of MX beamline instrumentation is leading to ever-stronger emphasis being placed on brevity of execution as the main design goal for data collection protocols, often to the exclusion of other criteria that would aim at achieving higher data quality. This can be counter-productive, especially, but not only, for phasing experiments.
Global Phasing, among others, has been interested in bucking that trend by creating combined capabilities for the fast design of optimal strategies and the direct supervision of their execution on an actual beamline. GPhL’s approach has been to aim for a full "third-party design and control" capability rather for than separate add-on programs that would need to be invoked by local software on each specific beamline or group of beamlines running under the BCS.
To make this capability as transferable as possible across the huge diversity of beamline instruments and BCSs, finding the correct level of abstraction for all the components and processes involved is of paramount importance. This requires focusing on the stage where description and action must dovetail.
For a strategy to achieve optimality, it needs to rely on complex sequences of measurements dictated by scientific criteria and imperatives; while in order to achieve "executability" it must be translatable into a sequence of instrumental actions available from the BCS.
A common vocabulary is therefore required for the instructions in terms of which any complex strategy can be expressed, and on the basis of which the combined instrumental actions needed to execute these instructions can be requested from the BCS.
It is precisely the purpose of the GPhL Abstract Beamline Interface to define a common vocabulary for both the description and execution of designed strategies. It intentionally excludes the specification of much of the information needed to design a strategy in the first place, and it abstracts the invocation of the BCS into calls to services without any reference to their underlying implementation.
The Abstract Beamline Interface is being used internally by GPhL as part of its tools for achieving the initially stated goal of "third-party design and control" whereby optimal experiments can be both designed and driven by third-party software.
This Interface is being presented here to BCS developers on the rationale that the more a BCS uses it as a template, the simpler and more natural the mapping will be between the instructions inherent in the vocabulary and the detailed internal actions that execute them. As the former are predicated on fulfilling broadly agreed scientific optimality criteria, the core of the specification should prove fairly universal and stable, and its general adoption within the relevant parts of a BCS can be expected to save both development and troubleshooting time even outside the pursuit of the "third-party design and control" paradigm.
The scope of the Interface is currently rather narrow: it is designed to accept sequences of actions that define the collection of diffraction images from a single centred sample, and cater for the minimum user interaction that is needed to generate an optimal data collection strategy and execute it. In the future, the scope may be widened to allow for:
-
multiple centred positions on a single sample
-
multi-sample experiments
-
operations other than collecting diffraction images (e.g. fluorescence scans)
-
providing static instrument configuration data required by the strategy generation software
The Abstract Beamline Interface is not concerned with the specification of the communication protocol with the beamline control system. Our current developement is using the Java Message Service but we intend to support other protocols such as XML-RPC.
Similarly, the concrete interface itself is currently provided in Java only, but implementations could be written in any programming language that supports an appropriate communication protocol.
The current focus of GPhL’s development is a collaboration with Diamond Light Source on the long-wavelength I23 beamline, however we are actively working with other institutions as well. We are part of the collaboration working on the MXCuBE software that is used at several European synchrotrons. Data collections and a great deal of very valuable collaboration to support the methods development involved have taken place at X06DA (Swiss Light Source) and at PROXIMA1 (SOLEIL Synchrotron).
The Abstract Beamline Interface is currently under development, and is therefore subject to rapid change.
The origins of the Abstract Beamline Interface go back to a proposal made by GPhL to the MXCuBE collaboration in June 2012