Cinema:Bandit: a visualization application for beamline science demonstrated on XFEL shock physics experiments

A new visualization tool, Cinema:Bandit, and its demonstration with a continuous workflow for analyzing shock physics experiments and visually exploring the data in real time at X-ray light sources is presented. Cinema:Bandit is an open-source, web-based visualization application in which the experimenter may explore an aggregated dataset to inform real-time beamline decisions and enable post hoc data analysis. The tool integrates with experimental workflows that process raw detector data into a simple database format, and it allows visualization of disparate data types, including experimental parameters, line graphs, and images. Use of parallel coordinates accommodates the irregular sampling of experimental parameters and allows for display and filtering of both experimental inputs and measurements. The tool is demonstrated on a dataset of shock-compressed titanium collected at the Matter in Extreme Conditions hutch at the Linac Coherent Light Source.

1. Introduction

Experimental workflows and visualization techniques need to adapt to meet the demands of the next generation of shock physics experimental facilities. Recent technological advances are allowing material scientists to better investigate shock-compressed matter under extreme conditions (Nagler et al., 2015; Stan et al., 2018). For example, X-ray free-electron lasers (XFELs) now provide unprecedented spatial and temporal resolution to investigate phase transitions, compression, and strength of materials (Nagler et al., 2007, 2015). Parametric studies that combine high-pressure and high-temperature methods (Stan et al., 2018) with X-ray diffraction (Nagler et al., 2007, 2015) and optical diagnostic techniques (Hashim, 2016) allow scientists to not only study astrophysics, geophysics, and planetary physics but also to synthesize new materials with useful strength properties. In the near future, these experiments will be performed faster with orders-of-magnitude more data, up to 10 Hz at the High Energy Density Science (HED) Instrument at the European XFEL (Zastrau et al., 2017; Bolme et al., 2017; Madsen, 2011). However, at data rates up to 10 Hz, the data feed will be too fast for scientists to interact with each dynamic event or shot, which necessitates the development of automated processing and prompt display tools. These tools will facilitate informed decisions by scientists during an experiment to optimize their use of time at the beamline facility.

Traditional shock physics datasets have used diagnostics that measured the bulk volumetric response of the materials. The most common type of measurement made is velocimetry, which uses optical light (usually from a laser) to measure the velocity or displacement of material interfaces. These velocities can be related back to thermodynamic state variables using the fundamental conversation laws of mass, momentum, and energy (i.e. the Rankine–Hugoniot relationships). The Velocity Interferometry for Any Reflector (VISAR) is a common technique that was first implemented to make measurements on a single point (Barker & Hollenbach, 1972) and is now also used in a line-imaging version, which provides one dimension of spatial resolution (Bloomquist & Sheffield, 1983; Celliers et al., 2004; Bolme & Ramos, 2013).

The utility of X-ray diffraction (XRD) for diagnosing material response (e.g. phase changes, strain, and texture) to shock compression was recognized many years ago and was originally achieved by Johnson et al. (1970, 1971, 1972). Due to the X-ray source technology at that time, the experiments were extremely difficult to perform, and XRD was not adopted as a common technique in shock compression experimentation. During the past two decades, improvements in X-ray brightness at high-energy laser facilities (Kalantar et al., 2005), at X-ray synchrotrons (Turneaure et al., 2009), and at X-ray free-electron lasers (Nagler et al., 2015; Fletcher et al., 2015; Gleason et al., 2015; Gorman et al., 2015) has resulted in the widespread use of XRD for in situ measurements in dynamically compressed materials.

Real-time analysis and visualization of data is important to maximize the scientific productivity at beamline facilities. Automation within the heterogeneous hardware and software environments (Mangold, 2018; Figueroa et al., 2018) at beamline facilities has always been an active area of development. Many facilities have data management systems that enable users to automate analyses (e.g. Veseli et al., 2018), and there are a number of cross-platform tools to process and visualize XRD data, such as Mantid (Arnold et al., 2014), GSAS-II (Toby & Von Dreele, 2013), MAUD (Lutterotti et al., 1999), FIT2D (Hammersley, 2016), and DIOPTAS (Prescher & Prakapenka, 2015).

Our goal is to improve visualization of datasets for shock physics experiments at XFELs, particularly visualizing aggregated data in interactive views. In this paper, we present a visualization tool for experimental data exploration at beamline facilities and describe its inclusion in a continuous workflow. Our visualization tool, called Cinema:Bandit, uses multiple linked views (Roberts, 2005) and the visual comparison techniques of superposition and juxtaposition (Keim & Kriegel, 1996) to understand the relationship between many samples in an experiment as a whole. It allows disparate data types to be coherently visualized and explored, and it supports irregular sampling of experimental parameters, including experimental inputs, measurements and outputs, that can be displayed and interactively adjusted. To address the automation issues at beamline facilities, we demonstrate the use of Cinema:Bandit in a modular workflow with user-defined algorithms and tools that process the raw detector data at the beamline facility. In this paper, we provide a detailed description of our visualization tool Cinema:Bandit and the distribution of the software (Section 2). Then, we discuss the standardized Cinema database specification (Section 2.2) that our tool uses. To describe the visualization process at a beamline facility, we present an integrated experimental workflow implementation that was used for data processing and visualization during experiments at the Linac Coherent Light Source (LCLS) facility (Section 3). We show how Cinema:Bandit was used to analyze the results from a titanium experiment (Section 4). In particular, we demonstrate its ability to identify outliers or problematic data, direct experimental design, and compare ensembles of samples.

2. Cinema:Bandit implementation and description

Cinema:Bandit is a modular visualization tool that enables collation, visual comparison, and filtering for an ensemble of samples. It is a web-based tool that is part of a group of open-source Cinema tools, which is a visualization approach to address extreme-scale data analysis problems in the supercomputing and the visualization community (Ahrens et al., 2014). The tool is a Cinema viewer, hierarchically named Cinema:Bandit due to a visual similarity with a slot machine (a slot machine is also known as a `one-armed bandit'). In Fig. 1 we see the set of three data views (to the left of the screen) that respond to the user's interaction with the tool. These constantly updating data views are reminiscent of the three spinning wheels of a slot machine.

Figure 1 An overview of the Cinema:Bandit interface. The parallel coordinates plot at the top shows parametric (i.e. inputs and outputs) information about each run in an experimental dataset. At the bottom, the user can alternate between the VISAR, Diffraction Image, and Diffraction Graph views. Each view shows information that has been extracted from the experimental runs' data.

Cinema:Bandit falls under the general category of ensemble visualization, a method for using parameterized datasets, or ensembles, to display information to a user (Cox et al., 2013; Potter et al., 2009; Ferstl et al., 2016). This is illustrated in Fig. 1 where all runs are shown in the interactive parallel coordinate plot at the top. The interactive parallel coordinate plot is a multi-dimensional visualization that displays each parameter as a parallel vertical axis and each run as a polyline whose vertices are located on these axes. Additionally, Fig. 1 shows four interactive linked views: an interactive parallel coordinate plot at the top and three other views on the left-hand side. In Fig. 1, we display velocimetry profiles, XRD images, and XRD patterns; however, there can be any number of side views characterized by either line graphs or side-by-side images.

2.1. Implementation

The web-based tool is written in HTML and JavaScript using the Cinema Components Library (Tauxe et al., 2018) and D3 (Bostock et al., 2011). The Cinema Components Library is an open-source library containing components for querying Cinema Specification-D (Spec-D) databases and building web-based visualization tools (e.g. parallel coordinate plot or scatter plot). Since we leverage web-based technologies, remote visualization of data is possible, and users can open up many instances of the application by simply navigating to or double clicking the HTML page. Additionally, there are no necessary external libraries to install, which is ideal for the heterogeneous environments at different beamline facilities.

Due to web application security, Cinema databases need to be stored in a sub-folder under the Cinema:Bandit application folder on the filesystem. The source code and documentation are available for download from https://github.com/cinemascience/cinema_bandit. New releases of Cinema:Bandit will be posted at the same location.

2.2. Cinema database specification

Cinema visualization tools, such as Cinema:Bandit, use a standardized database (Rogers et al., 2017), which contains a set of sampled data, often in the form of images, along with simulation/experiment parameter information (e.g. pressure, temperature, and time delay). Each item in the database is a parameterized run that has a set of files representing line graphs or images. Cinema databases can be visualized through other open-source tools since they are composed of commonly used files types, e.g. CSV files or png images.

Fig. 2 shows an example of a Cinema Spec-D database (Rogers et al., 2017) for a shock physics experiment. A Spec-D database is a folder that contains a data.csv file at the top level and any number of data files (e.g. images or text files) that could be nested in sub-folders. The data.csv file is a CSV file with columns and rows, which can be saved from common spreadsheet applications. Each row represents a separate instance, experiment, sample, or run. Each column represents a parameter of interest, such as pressure, temperature, or velocity. In the data.csv file, users can optionally specify multiple associated data files at the end of the parameter list by adding the prefix FILE to the title. Each row in the database can then designate relative paths to the run-specific file for these columns. In Fig. 2, notice that the parameters are specified first and the data files are listed last. A blue highlight shows how one row in the CSV file points to many files in the Cinema database folder structure.

Figure 2 Example Cinema Spec-D database. Each Cinema database has a data.csv file as well as multiple folders that contain types of data (e.g. velocimetry profiles, XRD images, and XRD patterns). The data.csv file contains parametric information about the run as well as paths to corresponding file names.

Two run-specific line graphs or images can be defined in the Cinema database's data.csv file via the FILE column headers. The format is as follows: FILE_Title_Index (e.g. FILE_Diffraction_Graph_1). Columns with the same title will be grouped in the same view. For example, the Diffraction Graph view in Fig. 1 uses an index of 1 to represent the static XRD pattern (blue) and 2 to represent the dynamic XRD pattern (red). This is the mechanism to create new views in the left-hand panel of Cinema:Bandit. Fig. 3 shows the relationship between the columns of the data.csv file and the data that are displayed in views along the left-hand panel of the Cinema:Bandit window.

Figure 3 A breakdown of how columns in the data.csv file relate to views in Cinema:Bandit. Column headers correspond to the type of data to be visualized and entries point to file names containing data values or images.

2.3. View input format

Graph data files. Cinema:Bandit will draw superimposed line graphs if the value in a FILE column references a CSV file. The application will assume that the data are stored as a table of numerical data with two columns representing the x and y dimensions of a 2D line graph. The CSV files do not contain headers.

Image Files. Cinema:Bandit will draw images if the value in a FILE column references an image file. The resulting images need to be stored as common Internet image file types, such as png, jpg, or gif.

2.4. Visualization features

Filter and select. The parallel coordinate plot shows a multi-dimensional view of the parameter relationships between runs, and users can filter results by interactively selecting valid parameter axis regions for all dimensions on this plot. The line graph views show a superposition of curves from the selected regions in the parallel coordinate plot. Users can make an instance selection by either hovering over or clicking a line in the parallel coordinate plot or in a line graph view. Both the parallel coordinate plot and graph view highlight the selected instance (i.e. the red and blue curve in the line graph view from Fig. 1). The image views display two images that represent the selected instance for side-by-side comparison, and an info panel also appears, showing the selection's detailed parameter information. This unique visualization format allows users to interactively explore multiple data types through a single tool, while maintaining the context of their data through the parallel coordinate plot.

Multiple linked views. The filtered results and selection are linked across views making it easy to see parameter and disparate data relationships.

Pop-up display for parameters. When a run is selected, its data are highlighted in all linked views, including the parallel-coordinates plot, as shown in Fig. 1. A pop-up window also appears, as shown in the bottom right corner of Fig. 1, which allows the analyst to view the precise values for each parameter for the highlighted run.

Level of detail. Cinema:Bandit includes toggle zooming by positioning the mouse at the zoom location and moving the mouse scroll button up or down. Once zoomed in on an area, the user can pan by clicking and dragging the view. Fig. 4 shows three examples of zooming using Cinema:Bandit. Notice that for the image view the images are coordinated such that they are zoomed into the same location for comparison.

Figure 4 Cinema:Bandit provides a zooming capability that allows the user to examine finer details of their experimental results. Note that, with diffraction images, views are linked so a zoom into one region provides the equivalent zoom in both images.

Data refresh. Cinema:Bandit refreshes automatically based on changes to the Cinema database. The application will monitor the data.csv file described in Section 2.2 every few seconds for file size changes. The file size is monitored to reduce overhead and increase interactivity. For example, if a new run is added, the application will detect it immediately and add the new run to the visualization. The current filter and selection will remain when a change is detected and added to the visualization, allowing the user to continue to investigate their current query. Occasionally, changes are made to the data.csv file that do not affect the file size. Therefore, periodically the application will load in the data.csv file to determine whether there are any subtle differences. This feature is key to providing automated visualization updates in a workflow.

3. LCLS workflow implementation

Cinema:Bandit was integrated into an automated workflow for a shock physics experiment at the LCLS beamline facility. Fig. 5 shows a high-level overview of our workflow where a single control script, using LCLS's data analysis software called psana, executes the data-processing workflow that includes three distinct steps. The left side of the figure shows the incoming raw data being distributed to three data analysis modules that perform data-processing and analysis tasks. Our workflow includes modules for extracting and recording the parameters of an experiment, processing velocimetry data, and processing XRD data. These modules are further described in Sections 3.1, 3.2, and 3.3. The output of each module is saved in text files and images, and then appended to a Cinema database, pictured in the center of Fig. 5. In this case, there are four sets of files: the data.csv file which stores parameter values and file locations (described in Section 2.2), a set of text files for the velocimetry profile data, a set of images for the XRD image data, and a set of text files for the radially integrated XRD patterns. Finally, the right side of Fig. 5 shows visualization of the data using Cinema:Bandit.

Figure 5 Data processing workflow for analysis of shock experiments and subsequent visualization with Cinema:Bandit. When a new run executes, raw data are read, processed, and saved into a Cinema database. The processed data are then visualized using Cinema:Bandit.

3.1. Parameter Module

For LCLS, we used the psana (Damiani et al., 2016) package to build a Python script that queries parameter values and saves them to the data.csv file. Common parameters that we have queried from the LCLS data systems are X-ray photon energy, delay between optical laser and X-ray pulse, and optical laser pulse energy. Similarly, the user can query and append parameters from local or shared spreadsheets (e.g. Google Sheets), including text descriptions or notes. The shared spreadsheet is continuously downloaded and used to update the data.csv file, which facilitates a collaborative workflow and allows multiple users to concurrently update run-specific parameters.

3.2. Velocimetry Module

The optical VISAR diagnostic (Barker & Hollenbach, 1972) measures the interface velocity of a sample. These data allow inference of material changes (e.g. elastic compression, plasticity, and phase transitions) by probing the bulk volumetric response during shock loading (Hashim, 2016). In the Velocimetry Module, a LabVIEW executable integrated with Python automates the processing of VISAR data to produce velocimetry profiles. The graphical user interface (GUI) is shown in Fig. 6. The panels titled Visar1 and Visar2 in Fig. 6 contain images of the spatial dependence of the material interface motion. For the Visar1 and Visar2 panels, there is one reference image when the shock has not arrived yet (top left) and the shocked sample image (top center). This LabVIEW executable generates the initial profiles, which then require the detection of the shock wave arrival (i.e. the abrupt rise in the velocimetry profile) and phase matching for the finalized velocimetry profiles. We employ a Python-based module that determines the discontinuity in the profile due to the arrival of the shock wave and then searches for the best-matching phase differences.

Figure 6 Screenshot of the automated VISAR analysis tool for velocimetry extraction.

3.3. X-ray Diffraction Module

The spatial locations and orientations of the X-ray detectors must be calibrated before they are processed to produce images and radially integrated diffraction patterns. Experiments at LCLS typically use several X-ray detectors, which are calibrated and assembled into a single image. In order to automate the geometric projection and aggregation of the detectors, our LCLS workflow contains a Diffraction Module as depicted in Fig. 5. A Python executable within the module transforms image data from a set of area detectors to a plane perpendicular to the beam path, and then writes the image and diffraction pattern to disk. This executable makes extensive use of tools from the open-source PyFAI (Ashiotis et al., 2015) package. The ensemble of images and diffraction patterns from experiments are displayed in Cinema:Bandit as shown in Fig. 1.

3.4. Timing

The LCLS workflow described in this section has successfully been used during several experiments in the Matter in Extreme Conditions (MEC) hutch at the LCLS for real-time data processing and visualization. In each experiment there was ∼7 min between shots, i.e. the entire data-processing workflow for a shot should be completed within 7 min. The time until the data files are visible, or can be queried and accessed using the psana interface LCLS, is variable, but typically the data are available within 10–30 s of the shot. In the described workflow, the automated parameters (Section 3.1), velocimetry (Section 3.2), and XRD (Section 3.3) modules were serially executed. The automated parameters module completed in <5 s, the velocimetry module completed in <5 s for a time series of 1000 timesteps, and the XRD module completed in <5 s for an array of two CSPad (Hart et al., 2012) detectors each taking 1940 × 1942 pixel images. The auto-refresh rate, described in Section 2.4, for the Cinema:Bandit HTML page was set to 5 s. Therefore, the latest shot parameters, velocimetry, XRD images, and the XRD patterns were visible in Cinema:Bandit within 50 s of the shot (or 20 s after the data were available). This timescale was acceptable based on our shot rate, but for faster data acquisition rates additional optimizations could be made, e.g. execute modules in parallel.

Aside from reducing the time from shot to visualization, the implementation of an automated workflow frees two additional analysts during the experiments. Prior to the implementation of the workflow, the velocimetry and XRD analyses used GUIs for the tools described in Sections 3.2 and 3.3. A dedicated person on each tool could load, analyze, and visualize the latest shot within 3–5 min, leaving approximately 1–3 min to interpret the results before the next shot.

4. Results

The web-based visualization tool Cinema:Bandit (Section 2) and the workflow tools (Sections 3.1, 3.2, and 3.3) have been used to process and visualize data from a titanium experiment at the LCLS. Titanium is a constituent for many alloys used in demanding engineering applications because it is both strong and lightweight. An experiment was run at the LCLS to understand the elastic response, plastic flow, and phase transitions of titanium via the shocked response from pure and alloyed titanium. The purpose was to determine the relative contribution of defects and impurities to the dynamic response at high pressures. Here, the experimental samples consisted of polycrystalline or single-crystal titanium foils, and the shock compression was created using an optical laser. The dynamic response was examined while varying the stress (by adjusting the laser energy), varying the delay between the optical laser and the X-ray pulse, and varying features of the initial material. Velocimetry data were collected using a VISAR system and XRD images were collected with an array of CSPad (Hart et al., 2012) area detectors at the MEC (Nagler et al., 2015) instrument at LCLS. In this section, we use this titanium dataset to demonstrate how the visualization tool Cinema:Bandit can be used to identify outliers or problematic data, direct experimental design, and compare ensembles of samples.

4.1. Identify outliers or problematic data

The axes in the parallel coordinate plot of Fig. 7 display information about the material tested (`Campaign'), run number, delay time, pressure, free surface velocity, and information about the optical laser energy. To demonstrate the capability of Cinema:Bandit to identify problematic data and outliers, Fig. 7 shows the integrated XRD data for many experiments. There are two plots that are visually easy to identify as outliers — one is highlighted in blue and the other one lies below the baseline. These outliers were the result of the baseline detector readout being suddenly influenced by the strong electromagnetic pulse that is generated when the high-energy optical laser hits the target near the X-ray detectors. These effects are intermittent, which is why they were only observed on a few of the shots. By using Cinema:Bandit, these outliers can be easily identified, and the parameters for these runs evaluated through the interface. These samples can be repeated with the same parameters, which would improve the completeness of the dataset for subsequent analyses. Due to the modular structure of Cinema:Bandit, one could envision incorporation of statistically based error-checking algorithms in future versions.

Figure 7 Outliers where the baseline of the X-ray detector created errors in the data. The blue line in the Diffraction Graph shows where the detector readout after the shot is erroneously being influenced by a strong electromagnetic pulse. The red line in the same graph shows the static integration curve before the shot.

4.2. Direct experimental design

The parallel coordinates plots along the top of the Cinema:Bandit display window allows filtering and exploration of the scalar or text values associated with an input or output of the experiment. A major utility of the parallel coordinates is that the values displayed can be gathered from a variety of sources, and they are added to the database to facilitate quick display and interaction. Two examples are shown in Fig. 8 of how the parallel coordinates display can assist in experimental design. Fig. 8(a) shows plots where the line plots have been filtered to a single type of starting material on the first parallel coordinate axis (Campaign = GF-HP). On the middle axis (Pressure), it is clear that for this starting material, in the pressure region of 40–85 GPa, data are absent. Cinema:Bandit makes such observations easy to visualize, allowing the user to quickly determine that data in this range of conditions were missing and allowing the experimental plan to be altered accordingly. Fig. 8(b) shows a different example in which the filter on delay time was set to values >11 ns. On the center axis (Pressure), it is clear that there are no data at these late delay times for pressures >32 GPa. Since the objective of the experiment included examination of the material behavior as a function of delay time and pressure, the experimenter might choose to revise the experimental plan to fill in data in this region.

Figure 8 Parallel coordinates region of the Cinema:Bandit display showing examples of how the parallel coordinates can be used to assist experimental design. (a) Data were filtered to show a single material type (GF-HP). On inspection of the center axis (Pressure), it is apparent that there are no data in the pressure range 40–85 GPa (highlighted in red). (b) Data were filtered by delay time >11 ns. The center axis shows that there are no data at pressures >32 GPa (highlighted in red).

This illustrates how Cinema:Bandit can be used to quickly identify and refine the parameter ranges to ensure adequate sampling to achieve the scientific objectives.

4.3. Compare ensembles of samples

For efficiency, two separate titanium experiments were being run at the same time (runs labeled 339–360 in Fig. 9) using a single material type (Campaign = GF-HP). The odd-numbered shots had pressures between 4.2 GPa and 13.7 GPa while the even-numbered shots had pressures between 21.9 GPa and 31.2 GPa. Fig. 9 shows the visualization tool for all odd-numbered and even-numbered runs. It is clear from the velocimetry view in Fig. 9 that the two sets of shots exhibit different behavior and that it is useful to visualize them separately. Cinema:Bandit allows users to open up several applications by opening up multiple tabs in a web browser application. Each tab can have different parallel coordinate plot filters, allowing users to monitor and explore multiple experiments at the same time.

Figure 9 Example of separate studies being run at the same time using a single material type (GF-HP, runs 339–360). (a) Cinema:Bandit shows the studies together with both low (blue) and high (orange) pressures. Alternatively the studies can be viewed separately by filtering out low (b) and high (c) pressures in two different browser windows.

5. Conclusion

As shock physics experimental methods advance, it is important for visualization techniques and automated workflows at beamline facilities to evolve. We presented a visualization tool called Cinema:Bandit that provides interactive visualization of aggregated datasets. The implementation of this tool was described for data from a shock physics experiment on titanium at LCLS. Cinema:Bandit is a visualization tool that allows scientists to focus on exciting scientific discoveries at the beamline facility rather than error-prone, tedious data processing tasks.