[Xrays@aps.anl.gov] (no subject)

Wed Jun 21 17:08:45 CDT 2006

In this mail I'll summarise my recommendation for an APS software strategy within the field of hard x-ray materials imaging. My background is 15 years of synchrotron instrumentation and development mainly in Europe. In particular our group has collaborated closely with ESRF on algorithm development and automisation at the Materials Science beamline ID11. My connection with APS is mainly via a 3 year long development project at Sector 1-ID.

The thoughts on implementation below originate to a large degree from Andy Götz at ESRF and from Søren Schmidt at Risø.

Relevance

Imaging of materials (in the broadest sense of the word including diffraction, fluorescence, phase ... contrast and including use of tomographic reconstruction as well as scanning principles) is one of the great success stories of third generations synchrotrons. With new capabilities like nano-characterisation and with increased awareness in the materials science community, the user group is bound to increase.

Put schematically, the field faces three challenges:

*	High throughput. The many new users and the natural drive towards matrix studies with many samples rather than just one-sample feasibility studies makes automisation and standardisation a clear issue. Most users would also demand that the time it takes to perform data analysis at home is reduced from ~1 year to 1 week or preferably handled on-line (similar to characterisation with e.g. electron microscopy)  
*	 In situ studies. Combined sectioning/electron microscopy machines are now on the market, with a spatial resolution of 50 nm or better. This emphasise that the main role of the synchrotron will be in dynamics studies, as these by definition cannot be made using invasive tools. For in situ studies on line visualisation is crucial, in part to steer the experiment ("having seen this global map I now want to focus on this part of the sample"), in part to learn whether the experiment was successful ("did anything nucleate in this sample during the heat treatment?") 
*	Data handling. The combination of more powerful detectors/computers and the wish for fast in situ dynamic studies implies that we should expect >1 Tb of data per day. Storing, reducing and analysing this data on line is beyond the reach of any user and requires an APS  strategy  

In one sentence, it is widely recognised that the main limitations of hard x-ray imaging today are software and detectors. 

Suggested strategy

One may define 3 levels of operation:

1. Basic interfacing:

There should be a standard way of interfacing all hardware: detectors, furnaces, stress rigs, encoders. My suggestion would be via platform independent device servers, such as the TACOs developed by Andy Gotz at ESRF. 

There should be one generally accepted program for basic control of motors, interfacing to the device servers, data handling (directories) and logging. There are a number of programs, which all can do the job, but I suggest spec, as I believe this is the one that most people are familiar with. (It may be that a lot of the spec functionality is superseded later on by more high-level programs - see below - but one needs from day one something robust for these key features.)

For commissioning, debugging etc. APS should continue to rely on  EPICS. However, the regular user should not have to deal with this low level of control. 

The architecture should allow all data to be handled immediately by a cluster, if needed.

Each imaging beamline should be associated with one "interfacing" expert. The aim should be that users simply should not worry about interfacing at all !

2. Image analysis and data reduction

There are a number of image analysis operations which are regularly performed on images. These include: visualisation, new data format, rotations/transformations, background subtraction, corrections for spatial distortion and flat field, deconvolution with point-spread-function, normalization of intensity, screening, polar transform (so-called caking), and identification and characterisation of areas-of-interest such as diffraction spots.

All of these operations can be handled by an existing program like FIT2D, which however is not well suited for high throughput. Instead these operations should be coded in machine language for maximum speed. The aim is that such operations per default is performed automatically and that users most of the time do not take home raw data.

To be able to keep up with the input data - 2D detectors can read out in milliseconds - long-term it is probably needed to include distributing images over a set of nodes in a cluster. However, a slower analysis would be acceptable as a start (it is much better to be able to see 10% of the data on line than 0%). 

The user would need to tell which operations to include. This could be done by a small primitive GUI or perhaps just in spec. 

3. Data analysis

Data analysis in imaging is characterised by application of large mathematically-heavy programs like reconstruction, segmentation and grain mapping algorithms. The output are 3D renderings of the materials investigated. Following that science specific quantification programs are applied which measure geometry, frequency, correlations etc.

Developing these algorithms is very much an on-going task which furthermore requires substantial resources and mathematical insight. Some users will be interested in "standard products" like a filtered backprojection reconstruction in conventional tomography, while others will arrive with programs of their own or wish for other algorithms, which for their particular case might provide better resolution or be faster. Hence, I believe APS should have a dual aim:

- maximum ease/flexibility for experienced users to bring own software and get that fully integrated in the on line analysis chain

- identification of some standard tools for routine use and optimisation of these with help from the relevant expert users. 

At ESRF, Andy Goetz has suggested a "plug-and-play" solution with a GUI based on Eclipse. This seems very powerful. In particular: 

- The GUI itself is already made, is independent of the scientific modules and includes 2D and 3D plots. This e.g. implies that one should be able to make first use of this program with a relatively modest effort. 

- It should be able to combine spec commands with the image analysis operations identified in 2 above and with calls to user functions of relevance to 3.

- It allows for direct interfacing to MATLAB.  MATLAB is in my view an excellent tool for "on-the-fly" analysis.

- Each user can have their own GUI, such that the information they get on the screen is customised to their needs and is the "same as last time". First-time users can get a "standard GUI".

In the 5-10 year perspective I foresee that the shear data-load will be so heavy that one needs to approach the issue of data analysis and reduction in the same way as it is done today in particle physics. Søren Schmidt and others at Risø has worked for the last 3 years on the backbone of such a system, known as FABLE.

Finally I recommend that all software is open source, such that one can take full advantage of specialised modules written by users and parallel efforts at other synchrotrons. 

I believe the above recommendations would also apply to beamlines specialising in diffraction, including crystallography.

Status

Being a user with a long-term proposal running at both sector 1 at APS and beamline ID11 at ESRF makes a direct comparison natural for me: 

ID11 at ESRF completed phase 1 above >5 years ago and have nearly completed phase 2. Work has just begun on phase 3. In contrast, Sector 1 at APS is presently still working on phase 1.  

(To be fair the group at APS has the edge on ESRF in other aspects, such as optics.)