9 The processing flow in a data exploration session

The general notion of Processing flow is that from the opening of a mass spectrometric data file to the end of the data exploration session, all the integration steps elicited by the user of MineXpert are recorded in such a way that the program will be able to run them all in memory when new integrations are performed.

Let's take an example: the user works with ion mobility mass spectrometry data and is exploring the efficiency of ion mobility separation of ions of the same molecule (say, ubiquitin, for example) as a function of a number of instrument setting parameters that are modified during the acquisition.

Note

The dataset used for Section 4.6, “ Chained Integrations ” and this section was kind courtesy of Dr. Valérie Gabelica and correspond to a work entitled Optimizing Native Ion Mobility Q-TOF in Helium and Nitrogen for Very Fragile Noncovalent Structures published in JASMS with DOI: 10.1007/s13361-018-2029-4. Many thanks to Dr. Valérie Gabelica (at the time at IECB, Bordeaux, France) for permission to use her data set.

For the first two minutes of the acquisition (min [1-2]), the instrument parameters tend to let the ubiquitin adopt a more regrouped, or condensed, tridimensional shape. The ions will thus have a drift time corresponding to that shape (see below, where this is demonstrated). During the next two minutes of the acquisition duration (min [3-4]), the instrument parameters are modified to induce a gradual defolding of the oligopeptide, which leads to an increased drift time compared to that observed in the first two minutes of the data acquisition. Three more such steps are carried out (see below).

Now, the user wants to precisely quantitate the ions that arrive to the detector during these five acquisition time ranges so as to quantitatively compare the ion mobility-based separation of the ubiquitin ions as a function of the different instrument settings.

There is one more consideration to this data exploration session: the ubiquitin molecule is ionized in the [2+-8+] range and the user wants to only compare ion counts for the 6+ charge level.

What would be the sequence of ProcessingStep events in the exploration to achieve what the user wants? This is what is described in the text below.

One now needs to confirm that each ion mobility mass spectrum's peak actually corresponds to specific mass spectrometer settings as described in the introduction of this section. Achieving that is very simple: select the RT button on the right hand side of the plot window and integrate to a TIC chromatogram each individual peak (starting from left peak at ion mobility drift times in the [26-29] ms range) up to the last one on the right. The result (Figure 9.6, “Retro-integrations from ion mobility spectrum peaks to TIC chromatograms ” ) shows that indeed the different ion mobility peaks correspond to acquistion time ranges that are neatly discriminated by the integrations.

The first chromatogram is the full acquisition's mass data file's TIC chromatogram and all the chromatograms below are the results of the retro-integration from each ion mobility peak to the corresponding TIC chromatogram (which, in the end, could be called XIC chromatogram, for extracted ion current chromatogram).

Figure 9.6: Retro-integrations from ion mobility spectrum peaks to TIC chromatograms #

As shown in the sequence of images above, each time a new integration is performed, a corresponding ProcessingStep record is added to the general ProcessingFlow object. This is visible each time in the text that is displayed in the small window right of the plot window.

So, what is all this demonstration about? Well, the question is, how were the intensities calculated, as shown in Figure 9.5, “Intensities are determined for the various ion mobility peaks ”? To answer this question we need to recall what happened at each new step of the ion mobility mass spectrometric data exploration: a new ProcessingStep record detailing all the bits of the integration was added to the ProcessingFlow object that is systematically attached to any plot in the program. Each plot that is plotted as a result of an integration has thus a corresponding ProcessingFlow object that it inherited from the plot at which the integration took place.

This is visible by reading the ProcessingFlow text shown in the figures above and by ascertaining that new ProcessingStep records are added to existing ones. This feature of adding to the ProcessingFlow a new ProcessingStep record for each new integration fully documents the history path that leads to any plot in the program, right starting from the very first step, that is, the reading of the data from the file on disk.

When the user integrates one ion mobility spectrum's peak to INT, the program gets the ProcessingFlow for the plot and plays—in memory— all of its ProcessingStep records right from the full data set that was initially read from disk. Playing all the steps one after the other effectively restricts the scope of the initial mass dataset to a limited subset. The set of ProcessingStep records contained in the ProcessingFlow thus acts as a multi-component data filter.

In the end, all the mass data that could “pass” all the ProcessingStep records have their ion count summed up to the intensity value that is displayed as a result of the integration.

In the previous section, we saw how ProcessingStep records are added to the ProcessingFlow object that documents the history of any given plot in MineXpert. In the examples above, all the integrations did involve the initial dataset and subsets of that dataset as documented by the ProcessingStep records, such that it is effectively possible to replay all the ProcessingStep records from the first one to the last one: the logical link between the various plots and the initial dataset as read from disk has never been disrupted.

There are situations where this stops from being true. And this is what this section is all about.

Let's take an example based on the same dataset as that used in the previous section. At one moment (Figure 9.3, “Isotopic cluster of the 6+ ion”) the user wanted to ascertain the charge of the ions beneath a given isotopic cluster. That process involves extracting and plotting the centroid of each isotopic clusters' peak that is selected by the mouse dragging movement.

The centroids bars plot that is plotted into the same plot widget that the user is selecting in Figure 9.7, “A centroids bars plot is no more logically linked to the initial mass dataset”, is no more linked to the initial mass spectrometric data set.

Because the centroids bars plot is a pure creation of data and not the result of a conventional initial dataset-based integration, its data are no more logically linked to the initial mass spectrometry dataset. The ProcessingFlow's last ProcessingStep record shows this as an integration from source type MZ to destination type NO_DATASET_MZ.

Figure 9.7: A centroids bars plot is no more logically linked to the initial mass dataset #

What does the integration destination type NO_DATASET_MZ do in the context of the use of the centroids bars plot later? The presence of NO_DATASET_MZ as either source or destination integration type stops MineXpert from trying to use the initial dataset when actions are requested on that centroids bars plot. Let's say that the user wanted to integrate the centroids bars plot to an intensity (INT) or a mass spectrum (MZ) for later use (whatever that later use may be). The user would select the centroids bars plot and then check the MZ button on the right hand side of the plot widget and perform a -click-drag operation over the centroids bars plot. MineXpert would interpret that as a normal integration, look for the <emphasis>m/z</emphasis> range covered by the mouse drag movement and try to replay all the ProcessingStep records in the ProcessingFlow. If there was no ProcessingStep record documenting that the centroids bars plot is no more logically linked to the initial mass dataset, the result of that last integration would be obtained for the isotopic cluster graph plot displayed in the figure, not for the centroids! Which would of course mean nothing.

The ProcessingStep record listing NO_DATASET_MZ as an integration source and/or destination type allows for interesting computing possibilities. For example, when an integration such as that mentioned above is tried, the program checks the compatibility between the source plot data which is, in this example, the centroids bars plot (source type NO_DATASET_MZ) on the one hand and the integration destination type, which is either a mass spectrum (MZ) or an intensity (INT). The result of check is positive because the centroids bars plot is indeed <emphasis>m/z</emphasis> data (source type NO_DATASET_MZ) and also an intensity can be readily computed from the plot itself. In this case, the integration to a mass spectrum would work: the new plot would be a centroids bars plot exactly as the parent plot was a centroids bars plot. In this case, the data of the plot itself is used to create the requested artifact: a new MZ or a INT intensity value to be printed in the Console window.

Let's imagine that the user did not want to integrate the centroids bars plot to a mass spectrum but to a drift spectrum. The program cannot comply: how can a source plot of type MZ be used to plot a destination plot of type drift spectrum (DT) without needing the initial mass spectral dataset, exactly as performed in Figure 9.4, “Ion mobility (drift) spectrum ”?

Tip

When performing integrations starting with plot data that have no more a logical link to the initial mass spectral dataset, the program only allows performing the requested integration either:

• If the integration destination type is the same as the source integration type (NO_DATASET_DT to DT, NO_DATASET_MZ to MZ, NO_DATASET_RT to RT), in which case the source plot data are used for the integration;

• If the integration destination type is INT intensity value. In this case also, the source plot data are used for the computation.