SPMS data imported within FATES is stored within separate variables for the experiment description, the particle data, and the spectral data. A SPMS data set imported into MATLAB via FATES is referred to as a FATES study, the data architecture of which is comprehensively detailed in the FATES manual (Supplement M-4). Logically, the data mostly consist of one-to-many relationships from study to experiment, experiment to particle, and particle to spectral peaks. The data are most typically loaded once and then accessed and filtered in bulk. Therefore, it is more efficient to organize the observed measurements into denormalized matrices for particle and spectral data, where key information is duplicated in each matrix.

Each FATES study stores a data structure that contains a number of user-defined fields (e.g., instrument name, operator, location) to describe the experiment in which the data within the study were collected. Each row of the structure describes a unique experiment, which pertains to a unique experiment identifier (ID). All particle data (e.g., speed, power of desorption–ionization laser pulse) are stored in a MATLAB matrix. More specifically, each particle within a FATES study has a unique two-column particle ID. The first column of the particle ID is the experiment ID, previously described, to which the particle belongs. This framework allows users to easily select for particle or spectral data collected during a specific experiment within a FATES study that contains data from multiple experiments. The mass spectral data for all particles in the FATES study are held in an external binary file. Users can easily and quickly retrieve spectral peak data (e.g., m/z, area, height) for user-selected particles using functions provided by the FATES toolkit (Supplement M-6). The spectral data when imported are then stored in MATLAB cell arrays or matrices. Each peak for all of the spectra within a FATES study has a unique four-column peak ID. The first three columns of the peak ID are the experiment ID, particle ID, and polarity indicator of the spectrum to which the peak belongs. Note that each FATES study contains auxiliary data structures that list the name of the variable (e.g., particle speed, peak area, peak ID) that each column in a data matrix holds. Thus all data within a FATES study are self-contained and self-described, from experimental conditions to peak information. Therefore despite the flexibility of the FATES framework, users can still share FATES studies without confusion or need for external README files to determine the source and identify of the data.

Considerable work has been completed to optimize the FATES framework for memory demands, speed, and ease of use. An ATOFMS data set collected at Bodega Bay, CA, in February and March of 2016 is used throughout this paper to illustrate the speed of data analysis within the FATES toolkit. This data set contains 1 386 042 dual-polarity single-particle mass spectra as well as particle data for an additional 11 454 356 particles that were detected in the light-scattering region but did not generate spectra. All FATES analysis is performed in MATLAB 2014b with an Intel Core i7-4930K CPU running at 3.4 GHz with 16.0 GB of RAM. Run time comparisons, summarized in Table 2, are made using the same computer utilizing a version of YAADA, which had been maintained by Kim Prather's research group to be compatible with MATLAB 2013a.

To begin working with a SPMS data set, a new FATES study has to be created (Supplement M-2). This process only needs to occur once for any data set, but the source code was still designed to minimize the time for study initialization. Despite the large size of the Bodega Bay data set, the creation of the FATES study only took 28.4 min. Even initiating a subset of the Bodega Bay study roughly one-tenth of the FATES study (127 077 dual-polarity mass spectra) in YAADA still required 20.8 min. Small ALABAMA and TSI ATOFMS data sets were also initiated expediently in FATES (Table 2). Note the version of YAADA maintained by Kim Prather's research group is not able to import these data sets into MATLAB for comparison. FATES has also been designed so that additional data can be added to an existing study without having to re-initialize the entire data set (Supplement M-A). This is especially useful for field studies, where daily examination of the data is required, but initialization of increasingly large data sets can become onerous and time consuming.

Once a FATES study is initiated, it is crucial to efficiently handle the spectral data. Users may desire to examine data sets with millions of mass spectra, and each spectrum can contain hundreds of peaks. SPMS spectra data formats usually contain mass-to-charge (m/z) ratio and area for each peak, but they may also specify peak width, peak height, and other values. This amounts to many gigabytes of data, and therefore the trade-off between making all the spectral data available and managing memory requirements had to be taken into consideration. MATLAB facilities for tables were considered, but they are more appropriate for heterogeneous data, whereas in our case all the spectral data are numeric or binary indicators. We also found MATLAB memory mapped files to have unpredictable performance, and it was difficult to append data rows because matrices are stored in column order. We determined the best way to build up and maintain a large matrix of spectral data, without keeping it in memory, was to create a single external binary file, append to it as needed, and provide a lightweight interface so that FATES programs, or other users, could easily execute functions against the file. Essentially, this interface is an API (application programming interface), which takes a regular MATLAB command or script, shuffles data in/out of memory in blocks of rows, executes the commands against the data in memory, and gathers results. The block sizes are set to default values that are reasonable for current workstation capacities but can also be changed as appropriate in the future. The possible commands are unconstrained, but summaries and filtering operations are most appropriate and most likely to be called for.

In addition, the binary format minimizes both the time required to write and retrieve spectral data and the storage requirements for the file. Retrieving all 1 386 042 dual-polarity mass spectra in a single call from the external binary file created for the Bodega Bay study and loading it into a MATLAB array only took 3.3 min. It is important to note that this example is used for benchmarking purposes, but rarely would users need or choose to load into and hold all spectra information for entire large data sets within memory at the same time. The FATES framework automatically employs data pointers so that the whole binary file does not need to be read if the user is only attempting to retrieve spectra from particles which make up a subset of all the data in the FATES study. Run times for retrieving all and contiguous subsets (i.e., the raw data files from which the study was created were contiguous) of the dual-polarity mass spectra from the FATES and YAADA studies are summarized in Table 2. Retrieving a subset of 50 000 mass spectra from the FATES study (2.7 s) was over 6 times faster than in the YAADA study (17.3 s). Searching through and sorting data by particle information is also quickly performed in the FATES framework. By holding all hit particle data in memory, any operation querying the particle data does not require any data input/output calls and therefore is nearly instantaneous in MATLAB. For example retrieving the particle IDs for all submicron particles from the Bodega Bay study only took 0.01 s, while performing a similar analysis on the much smaller YAADA study required 0.6 s.

The quickness of the FATES framework depends partially upon minimizing retrieval calls to external files outside of the MATLAB workspace. Thus formatting of the data held within the MATLAB workspace has been carefully considered to minimize the memory demands of the FATES framework. Because spectral data are held in an external binary file, users can choose to store spectra data in the study at a high resolution without increasing the study's working memory. When retrieving spectra from the external binary file, users may specify the resolution to hold the data in the workspace. This feature allows users to tailor the resolution of the spectra in the workspace to its application and therefore the memory requirements. Mass spectral data loaded into the MATLAB workspace are stored in a single-precision floating-point format, saving memory compared to the standard MATLAB double-precision format, which requires twice the space. Particle data stored within a FATES study have also been formatted to minimize memory demands. If the user loads data into a FATES study for both detected particles that generated mass spectra (hit) and detected particles that did not generate spectra (missed), only hit particle data are stored in the particle matrices in MATLAB. Most data analyses utilize spectra, and therefore only hit particle information is necessary, but hit particles usually make up a small fraction of total particles detected by the light-scattering region of the SPMS. Therefore storing missed particle data in MATLAB memory would take up large amounts of space needlessly. All missed particle data are written to an external binary file and can be loaded by the user into MATLAB using a script provided in the FATES toolkit. Furthermore particle data stored in MATLAB memory are split between a single-precision and double-precision matrix. It is not necessary to store most data collected for particles (e.g., speed, laser power) in a double-precision format, so this choice further relieves the space required to store all particle data in memory. Therefore storing data for 1 million hit particles in memory where three variables require double-precision format (particle ID, time) and three variables only need single-precision format (speed, size, laser power) only requires 0.036 GB, which is very feasible for most modern desktop computers. Finally because all SPMS data when loaded into a FATES study are held in native MATLAB data types, interacting with the data requires very few FATES-specific functions. Almost all common analyses can be patterned off a basic script, provided with demonstration data in the FATES toolkit and relying on a handful of MATLAB built-in functions and matrix indexing, which makes the FATES framework accessible and powerful for both expert and novice users.

While the FATES toolkit allows flexibility in script-based SPMS data analysis, graphical tools can also be an effective way to explore the data and quickly identify trends and patterns. To this end the FATES toolkit includes GUIs, built within MATLAB, which allow users to easily examine trends in spectra based on particle metrics such as size and time, and cluster and spectral characteristics. Figure 1 is a screen capture of the FATES spectra explorer guiFATES, displaying data for 46 432 particles. This spectra explorer has been modeled after ClusterSculptor, a SPMS data analysis GUI developed by Zelenyuk et al. (2008a) that has not been made publicly available. To initiate guiFATES, the user provides the function with the mass spectra, two user-selected particle metrics, and cluster data for a set of particles. A description of the functionality and abilities of guiFATES is given below.

The main panel of the guiFATES display is the heat map of the individual particle mass spectra. Each row is an individual mass spectrum with peak intensity indicated by color. The user can choose to display the provided mass spectra peak intensity utilizing a linear or log10 scale. The logarithmic scale makes it easier to visually detect relatively small peak intensities in the spectra, while the linear scale helps users visualize absolute differences between peak intensities. In Fig. 1 the logarithmic scale has been selected. Users can choose to provide any two characteristic particle metrics, such as particle size, time of detection, laser pulse energy, or total ion intensity, which are displayed in the left panels. In Fig. 1 particle time and size have been provided. Clustering information is displayed in the right panel. The cluster or group assigned to each particle is indicated by the color of the points on the right, while the location on the x axis is a user-provided clustering statistic for each particle. The clustering statistic provided for display in Fig. 1 is the dot product of each normalized particle spectrum with the normalized representative spectrum of the cluster to which the particle had been assigned. However, the user can provide any clustering or neighbor statistic they feel is effective for exploring their data set. The top plot in guiFATES is the average of all the provided spectra, and immediately below is plotted a select average cluster spectra, specified by the user in the display parameters. The line color in the average cluster spectra plot matches the colors used to indicate the assigned cluster for each particle in the right vertical plot. The bottom of the guiFATES windows contains all the display, sorting, filtering, and grouping parameters that the user may select and change.

guiFATES provides the user with many options for displaying and exploring the data, and all functionalities are thoroughly detailed in the manual (Supplement M-7). A check box allows the user to display all data with or without grouping by cluster. In addition the user can select to sort the data by any of the particle metrics in the vertical side panels or by a m/z value in the spectra. In Fig. 1 the data are displayed by cluster and sorted by size. Figure S1a in the Supplement is a screen capture where the same data are not grouped by cluster and have been sorted by peak intensity of m/z -35. While users may initially provide guiFATES with a large amount of data, they will likely desire to display smaller selections at a time to enable better visual exploration. This can be accomplished in a number of ways within guiFATES. Users can use mouse clicks to quickly zoom in and out of a single plot using MATLAB's native figure handling capabilities. guiFATES is designed so that when this occurs all plot axes within the GUI are scaled appropriately and instantaneously. Figure S1b is a screen capture where the user utilized this functionality to select the bottom half of the particles in Fig. S1a and also decreased the range of the m/z values displayed. For more complex selections users can enter in filtering parameters so that displayed particles only fall within a desired range of particle metrics, peak intensity of a certain m/z value, or any combination thereof. Figure S1c is a screen capture where the data, sorted by cluster, have been filtered by size (1–2 µm), m/z -35 peak area (0–3000), and clustering statistic (0.8–1). Lastly users can also choose to only display select clusters. Figure S1d is a screen capture utilizing the same filters as in Fig. S1c albeit limiting the display to only clusters 2 and 5.

These visual sorting and filtering methods enable users to efficiently inspect data sets and visually discover mass spectral trends, differences, and similarities both between distinct particle types and within populations of chemically similar particles. Due to the high variability and qualitative nature of single-particle mass spectra generated by laser desorption–ionization techniques, clustering algorithms utilized to group SPMS mass spectra within a data set often do not generate a one-to-one relationship between the number of chemical particle types in the population and spectra clusters generated (e.g., Giorio et al., 2012; Murphy et al., 2003; Rebotier and Prather, 2007; Wenzel and Prather, 2004; Zelenyuk et al., 2006, 2008a). Therefore it is necessary to leverage expert knowledge either to combine multiple spectra clusters, generated algorithmically, into a single chemical particle type or to further split clusters into smaller groups as has been noted in many SPMS studies of unconstrained aerosol populations (e.g., Dall'Osto and Harrison, 2006; Pratt et al., 2009; Qin et al., 2012). The authors emphasize that there is not a consensus on the most suitable algorithms and thresholds for SPMS analysis and suggest users investigate the previously listed references before embarking on mass-spectral-based algorithmic analysis. However, despite the conditions of initial clustering, guiFATES aids this process by allowing users to visualize all clustered particles at once and combine any number of clusters or split any cluster in any location during the data exploration process. Users can choose to output the particle identifiers of any cluster in the guiFATES window to the MATLAB workspace. All plotting, sorting, filtering, and grouping applications of guiFATES have been tested on a set of 100 000 particles with dual-polarity mass spectra, and at this size all updates to the displayed plots occurred nearly instantaneously, making guiFATES an appropriate and efficient tool for the large data sets common to SPMS analysis.

The advantages and benefits of this general method of data visualization and exploration for refining particle clusters have been discussed at length previously (Zelenyuk et al., 2008) and with the publication of FATES will be available to the SPMS community at large. A specific detail of note is that Zelenyuk et al. (2008) demonstrate that discontinuities in the particle cluster size distributions were characteristic of misclassifications of their mass spectra. Because this technique is not dependent on specific ion markers, it has the potential to be effective for a broad range of particle types but is yet to be extensively explored. guiFATES also enables future investigations of the extension of this cluster-discriminating technique to other common particle metrics, such as total ion intensity. Finally many studies have examined the influences of particle and experimental characteristics on the mass spectra generated from particles of uniform composition (e.g., Neubauer et al., 1998; Reinard and Johnston, 2008; Steele et al., 2003; Zelenyuk et al., 2008b). guiFATES can also be utilized in the exploration of these data sets consisting of a single particle type, where algorithmic grouping of particles utilizing mass spectra is unnecessary or even inappropriate.

FATES also includes two supplementary GUIs which allow the users to graphically select the particles to feed into the guiFATES spectra explorer. dendroFATES is a GUI where the user supplies the clusters and representative cluster mass spectra output from any clustering algorithm of the user's choice. The clusters are then automatically grouped into a cluster tree by a hierarchical analysis performed within MATLAB which is displayed in the dendroFATES GUI window. Hierarchical analyses have been utilized previously with SPMS data sets (Giorio et al., 2012; Hinz et al., 2006; Murphy et al., 2003; Rebotier and Prather, 2007; Zelenyuk et al., 2006), but a brief description is given here. The dendrogram links clusters in a binary fashion, creating new groups which are then further linked. Lower linkage heights indicate a higher degree of similarity between groups, and large distances between levels in the dendrogram are indicative of natural divisions in the data set. Figure 2 is a screenshot of the dendroFATES window with a dendrogram generated from the 30 most populous clusters generated using the ART-2a algorithm to cluster a subset of 166 666 particles from the Bodega Bay data set. Zooming in and out of the dendrogram is handled by MATLAB's native graphics functionality and makes it possible to supply dendroFATES with hundreds of clusters and still explore the cluster tree quickly and intuitively. Because the dendrogram allows the user to easily visualize similarities and natural groupings of clusters generated, it is an excellent tool to select clusters for further exploration of the particle and spectral data using the guiFATES tool. Clicking linkages in dendroFATES automatically opens a guiFATES window displaying all particles belonging to the selected node. When a linkage is selected, the fractional cluster contribution to the selected node is displayed on the right in the dendroFATES window, and the fraction of the selected node to the total population is also displayed in text. Figure S2 illustrates the guiFATES window generated with the node selection made in Fig. 2 when the user chooses to display particles by their cluster label (Fig. S2a) or grouped by the left and right branch (Fig. S2b). As illustrated in Fig. S2a, when guiFATES is populated by dendroFATES, the clusters are displayed in the same order as displayed in the dendogram. Therefore very similar clusters are adjacent in the guiFATES window, assisting intuitive visual comparisons and combinations of data. Because all FATES GUIs are in MATLAB and the user can also access the data programmatically, it is straightforward and fast for the user to iteratively select clusters from the dendrogram in dendroFATES, refine them in guiFATES, output new clusters to the workspace, and feed the new cluster results back into dendroFATES until the user is satisfied with the grouping of the data set.

The complexity of SPMS data sets means there are numerous relationships that could be explored, and predicting all desired comparisons is impossible. scatterFATES is another GUI used to populate guiFATES with user-selected particles. However, rather than grouping particles via clusters as in dendroFATES, scatterFATES creates a scatterplot of particles using any two particle data metrics the user supplies as the axes. The points are then color-coded by cluster or group. Figure 3 is an example scatterFATES window, where the -35 to -93 m/z ratio is plotted against particle size for the 166 666 particles that had been previously clustered. Once a scatterplot is created in scatterFATES, the user can click on the figure to draw regions within the scatterplot as shown in Fig. 1. All particle data within a created region can then be selected and automatically populated into guiFATES for spectra visualization and exploration.

FATES has been designed so that all aspects and functionalities of SPMS data analysis and exploration are contained within a single programming environment and language. To this end we developed calibFATES, a GUI to quickly scan through raw spectra data files before importation into FATES and generate calibrations to convert raw time-of-flight spectra to mass-to-charge spectra. calibFATES allows SPMS users to quickly visually examine generated spectra on the fly without any time-consuming processing, even during data acquisition, to ensure the quality and consistency of the data being acquired. While calibFATES is currently written to be able to read the raw spectra files generated by the ATOFMS and TSI ATOFMS, it could be easily modified to read in any raw spectra file (Supplement M-B). Figure 4 is a screenshot of a calibFATES window displaying a single uncalibrated raw spectrum. Users can scan through and display spectra contained in any raw spectra files within the folder. A calibration can be generated by setting selected times to entered m/z values. To generate as accurate a calibration as possible, it is suggested that users choose peaks with a diverse set of m/z values that span the SPMS mass spectral range and utilize multiple raw spectra to generate a single calibration. Generating calibration parameters from 20 peaks selected from five spectra has been found to produce generally satisfactory results for ATOFMS data sets. Calibration parameters can be output to a text file for future reference, and any calibration file generated can be loaded into and applied to the raw spectra in calibFATES so that the spectra are displayed as calibrated mass spectra rather than time-of-flight spectra.