Skip to content

Possible isotope peak assigned as precursor in mzML generated by timsconvert #77

@jingyiliu199703

Description

@jingyiliu199703

Hi!

We are working on visualizing identification results from .d raw data. To do this, we first used FragPipe to generate a psm.tsv file using the .d raw files as input. We then converted the same .d files to .mzML format using timsconvert. Our goal is to locate the corresponding MS2 spectrum in the mzML file for each PSM.
Since the scan numbers in the mzML files generated by timsconvert do not directly correspond to the scan numbers reported in psm.tsv, we used the retention time, observed m/z, and charge recorded in the psm.tsv file as search keys. Using this strategy, we were able to precisely match about 97% of the PSMs to their corresponding spectra in the mzML file. However, about 3% of the PSMs could not be matched correctly. For these unmatched PSMs, we applied very narrow retention time tolerances, and under the condition that the charge state was identical, we searched for the MS2 spectrum with the smallest m/z difference. Interestingly, we found a very clear pattern: the minimal m/z difference was consistently close to 1/charge. This suggested that an isotope peak might have been selected instead of the monoisotopic precursor.
To investigate further, we examined the MS1 spectra in the original .d raw files. We observed that the precursor selected for fragmentation had an m/z value very close to the value reported in psm.tsv. However, in the mzML file, the recorded precursor m/z was close to the isotope peak on the right side of the monoisotopic peak. Furthermore, when we examined the MS1 spectra in the mzML file at the corresponding retention time, we could not find the original precursor peak, but only the isotope peak.
Based on these observations, our interpretation is that timsconvert works perfectly in most cases, but in a small fraction of cases it may assign the precursor to the isotope peak instead of the monoisotopic peak. This results in an m/z difference of approximately 1/charge compared to the value recorded in psm.tsv.
We thought this observation might be worth reporting, and we would like to know whether this behavior is expected or whether it might be something that could be improved or corrected in timsconvert.
Thank you very much for your work and for your time.

Image Image Image

Best,
Jingyi

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions