Missing peaks MS1 quant centroid data

Missing peaks MS1 quant centroid data mstokes  2021-02-17

Hello everyone! We routinely use Skyline for MS1 quant with profile mode data and it works well. I have some centroid data that I'm trying to push through and I keep seeing missing peaks in certain files. When I do an XIC I can see the peak is there, the RT is good, the MError is good, but nothing in Skyline. I have tried running quant with both "Orbitrap" at a variety of resolutions and RT windows as well as "Centroid" with various ppm ranges and RT ranges, but to no avail. Many times it even looks as though there was a good MS/MS in the run that shows up as blank.

I have attached a screenshot of one example, peak is missing in Skyline in 2nd file but present in the XIC.

Has anyone else seen this issue or has ideas for a fix? Thanks!

Nick Shulman responded:  2021-02-17
Can you send us your Skyline document and your .raw files?

In Skyline you can use the menu item:
File > Share
to create a .zip file containing your Skyline document and supporting files including extracted chromatograms.

If that .zip file and your raw files are less than 50MB, you can attach them to this support request.

Otherwise, you can upload them here:

You might be able to figure out what is going wrong by clicking on points along the chromatogram where you expect there to be some signal. That will bring up Skyline's full scan viewer which will show you the spectra from the .raw file, and Skyline will show you how wide the m/z channel was that Skyline summed across to get the chromatogram intensity at a given point.
-- Nick
mstokes responded:  2021-02-17
Hi Nick! Will send everything through the upload link. Thank you!
mstokes responded:  2021-02-17
Uploaded: Skyline_Error_MStokes_021721
Nick Shulman responded:  2021-02-17
Thank you for uploading your Skyline document and those .raw files.

In your document, you extracted chromatograms from .mzXML files.

When I extract chromatograms from the .raw files that you sent me, I get a nice looking chromatogram. I am guessing that the problems that you are seeing have something to do with your mzxml files.

We do not recommend using .mzXML files since it is such an old format (.mzML is nearly always better). Skyline works best extracting chromatograms from your original .raw files, especially if you are using the "Centroid" option.
It's ok if your peptide search results were searched against .mzXML files. Skyline ignores the filename extension when trying to find if search results exist for a particular .raw file.
-- Nick
mstokes responded:  2021-02-17
Thanks so much Nick! We've always used mzXML but I will definitely try with the raw files on my end and let you know if it fixes it for me as well!
Brendan MacLean responded:  2021-02-17
I am working on rewriting the basic DIA tutorial (https://skyline.ms/tutorial_dia.url) which is unfortunately from 2014 and badly in need of an update. We would now generally recommend using centroided spectra for DIA. So, that is what I am suggesting, but I also just ran into exactly the same issue as you are reporting with the precursor spectra, and I just found that it has to do with interference shifting the m/z centroid out of the expected range.

I have attached a PDF that shows the case for the charge 4 peptide precursor GWCLESSQCQDLTTESNLLECIR++++ in the DIA tutorial with profile spectra extracted as described in the current tutorial (resolving power 35,000 at 200 m/z) and centroided spectra extracted as we would currently recommend by default (mass error +/- 15 ppm).

Seeing this and thinking about it makes it feel almost obvious. We recommend using extraction from centroided MS/MS for DIA, and over large proteomewide DIA data sets, this choice can be clearly seen to improve both mProphet detections and quantitative results, but fragment ion XICs from DIA MS/MS are more selective (lower interference) than precursor ion XICs from MS1. This has been shown many times in the literature, beginning with the original SWATH paper, and more recently we are finding that having the entire fragment ion series to choose from, you can generally pick very low interference fragment ions.

It is a bit shocking to see interference represented as the disappearence of the ion peak altogether, but it is in fact an expected problem when two interfering peaks have slightly different but unresolved m/z values.

So, I would guess that disappearing precursor peak signal is likely a relatively common effect in XICs from centroided MS1 spectra when the mass error caused by the interference excedes the extraction mass error tolerance. You can even see this in the profile MS1 chromatogram plot where the peak mass error is listed as -28.4 ppm. Of course, it is going to disappear when you switch to extraction from centroided spectra with +/- 15 ppm tolerance. The profile chromatogram peak is not necessarily well related to the targeted precursor abundance, because of the interference.

I suspect you are probably seeing the same effect. And I admit that I had not yet realized this as a possible impact of MS1 spectra being less selective than MS/MS.

Thanks for posting to the Skyline support board.

mstokes responded:  2021-02-17
Yes using the raw files works, thanks so much for the help!!!
mstokes responded:  2021-02-17
Thanks Brendan, the weird thing is it would still miss the peaks no matter what ppm I input for mass accuracy in the Full-Scan settings (I went up to I think 100ppm). In fact it seemed like more things were missed. Would that be because it is just pulling in more interfering ions that cause an even bigger shift?
Nick Shulman responded:  2021-02-17

Can you send us the file "210204_32617_as_F.mzXML"? There might be something interesting going on that we should try to understand.
-- Nick
mstokes responded:  2021-02-17
sure, will upload now.
mstokes responded:  2021-02-17
dropped 2 versions of 32617 in the same folder, "F" generated in GFY-Core, and "F1" generated in proteowizard.
Nick Shulman responded:  2021-02-17
Thanks for sending those .mzXML files.

The issue that you are running into is the same as this one:

The problem is that Skyline is mistakenly interpreting some of the spectra as "SIM" spectra, because the mzXML format does not have any metadata to tell Skyline what range was scanned across by the mass spectrometer. There is a more complete explanation about what is going on in the other support request.
We should fix this behavior so that Skyline never interprets spectra as SIM scans in mzXML files. For now, we recommend not using mzXML for chromatogram extraction.
-- Nick
jpaezpae responded:  2021-02-23
would this issue be solved using .mzML files or specifying the "--simAsSpectra" flag in msconvert ?
Nick Shulman responded:  2021-02-23

This particular issue would be fixed just by using mzML instead of .mzXML.
This issue is not affected by the "--simAsSpectra" flag.

Note that when I said Skyline treats it as a "SIM" spectrum, I am not using the term "SIM" in a way that is entirely accurate. Some people use a mass spec method which has two different types of MS1 spectra: survey scans which cover a very wide m/z range, and what Skyline calls "SIM" spectra, which cover a much narrower m/z range, and are presumed to be of higher quality in terms of things like resolution.
Skyline tries to detect when you are doing that, and if there are "SIM" spectra and regular MS1 (survey) spectra that apply to your peptide, Skyline extracts chromatograms for those two different sorts of spectra separately, and only ever shows you the "SIM" chromatogram.
Skyline decides that something is a "SIM" spectrum by looking at the width of the m/z range that it covers. Over the years we have increased the m/z range that Skyline thinks is the indicator of a high quality MS1 spectrum. In the current version of Skyline, any spectrum whose m/z range is less than 500 units is considered a high quality MS1 spectrum that contributes to a different chromatogram.

The "simAsSpectra" flag is something different, and is a flag that you might pass to msconvert, and tells it whether spectra which the mass spectrometer has identified as a "SIM" spectrum should be treated as a spectrum, or should instead be converted to one point in a chromatogram. Here, "SIM" is taken to refer to a technique of collecting data which looks like SRM data using a full scan mass spectrometer. For these sorts of SIM scans, you would probably tell the mass spectrometer to collect MS1 data over maybe only a 1m/z wide window, and you really were expecting to only get a single data point out of that spectrum. In this case, msconvert does not look at the m/z range of the spectrum, and instead looks at some metadata field on the spectrum to decide whether it's a SIM scan or not. I believe there is a checkbox in the Thermo method editor which will cause all of your spectra to be marked as "SIM". If you have done that, then you would also want to make sure that you pass "simAsSpectra" to msconvert when you create your .mzML file.
-- Nick