Skip to content

Untargeted LC-IMS-MS Workflow Overview

Compared to regular LC-MS, LC-IM-MS data is more complex due to the additional separation dimension. Since some terms might not be straightforward for new users, a basic explanation of IM separation principles and the terminology used within this documentation is provided here.

Supported formats

  • Vendor formats:
    • .tdf (Native Bruker LC-IMS-MS and MALDI-IMS-MSI format)
    • .tsf (Native Bruker MALDI-IMS-MS (single shot) format)
  • .mzML
    • Created via MSConvert from native Bruker data
    • Created via MSConvert from native Waters/Agilent data

Feature detection workflows

Ion mobility data can be processed in mzmine in two ways. The first few steps are different for the two workflows (see below).

  1. LC-IMS-MS workflow via ADAP Chromatogram builder and IMS expander ( recommended)
  2. LC-IMS-MS workflow via Ion mobility trace builder / Recursive IMS builder

While these lists might seem fairly similar, there are some differences in the processing approach. The LC-IMS-MS workflow builds ion mobility traces from the data in the mobility scans, whilst the LC-MS workflow builds EICs from the summed frames. For ion mobility data imported from .mzML files, accumulated frame spectra have to be built from the individual mobility scans after mass detection. Since the mass detection impacts the computation of accumulated frame spectra in the same way it would impact the ion mobility trace builder, the differences from this workflow and the ADAP workflow will be negligible.
However, frame spectra for native Bruker .tdf raw data are summed by the vendor library during file import. Here, the frame spectra are generated from the raw data and thus result in higher intensities, since the low abundant data points on the edges of the mobility and retention time peaks are not cut-off by the mass detection step. (see below) noise cutoff

Therefore, the more low abundant compounds might be detected, if the LC-MS workflow is recommended.

LC-IMS-MS data can also be processed via the regular LC-MS modules. If necessary, detected features can be expanded into the mobility dimension.

For this workflow, generation of summed frame spectra via the Mobility scan merging module is a mandatory step, if the data was imported from an .mzML file (automatically generated via native Bruker import).

The basic principle of the workflow is illustrated below: IMS_adap_workflow_01.png a, IMS heatmaps are accumulated to frame spectra (b). From the accumulated frame spectra, EICs are built (c). These EICs are resolved to individual features by a resolver (d). The resolved features are now defined by RT and m/z windows, which can be expanded in mobility dimension by the Ims expander (e). The resulting ion mobility traces (f), have to be resolved in mobility dimension afterwards, to create individual IMS features.

This figure shows the workflow in a more detailed manner, with additional optional steps. workflow-image

LC-IMS-MS workflow

The LC-IMS-MS workflow will directly build ion mobility traces from the raw data in the mobility scans. This workflow does not necessarily require summed frame spectra. However, if extracted ion chromatograms shall be visualized via the Chromatogram visualizer, the frame intensities are used. In case these are not present, the chromatograms will be blank. Note that feature intensities from the LC-IMS-MS workflow might not exactly match the frame chromatograms due to summing being executed prior to thresholding (for native Bruker data). Furthermore, multiple isomers might hide behind a single chromatographic peak.

Graphical comparison of LC-MS and LC-IMS-MS data

Data comparison

Page Contributors

Ansgar Korf, Steffen Heuckeroth, omokshyna, tdamiani

Last update: November 18, 2024 13:58:18