TIC area showing as NaN for some replicates

TIC area showing as NaN for some replicates aboatman  2023-04-17 12:21

Hi there - I am having an issue where the TIC area for some of my replicates is calculating as "NaN". Interestingly, when I view the TIC chromatograms, they are showing up as expected for all of the replicates. I tried re-importing results and that didn't fix the issue. I'm on Skyline-daily (Windows 10, 64-bit) version, using the small molecule interface. Will upload the .zip file to the file sharing as well, including results from one replicate with TIC NaN (AK_10) and one replicate that looks good (AK_11). Any help would be appreciated!

Nick Shulman responded:  2023-04-17 14:01
Thank you for sending those files.
When I look at "AK_10.d" in ProteoWizard SeeMS.exe, I see that the spectrum at 37.82495 minutes really does say that its total ion current is NaN ("not a number").
Do you have any idea why the value is that way?

I tried converting the .d file to .mzML, and that spectrum did not appear in the .mzML file: it skipped right from 37.8039 to 37.846.

We could fix this so that Skyline skips over NaN values when calculating the TIC, but it might be that there is some other problem with AK_10.d that we should not be ignoring.
-- Nick
aboatman responded:  2023-04-18 07:59
Hi Nick,

That's interesting. Now that I look more closely at the TIC chromatogram, there is a gap in the 37.8 minutes where it just disappears. I checked a few of the other samples and it does seem like the TIC drops off for a fraction of a minute in the NaN ones, while I didn't find that in the good ones. I then looked at these files in Agilent's IM-MS Browser software, and the TIC is briefly dropping to zero in those chromatograms as well.

I've asked around and we haven't seen this issue before in our group, but our best guess is that something in the electronics of the instrument just didn't collect for that frame. Seems like it would be useful to have a workaround to skip over NaN values, at least for these samples. But, I'm not really sure if this would ever be indicative of a bigger problem, and am not sure if that would be a good general rule to apply.

I'm attaching another few .d files in case it's helpful. AK_02 and 03 had the TIC area NaN (thanks for defining this acronym for me!). 01 and 04 were good.

Thanks for your help!
aboatman responded:  2023-06-22 09:59
Hi Nick,

It sounds like in our group we have occasionally seen an issue where the instrument doesn't collect scans for frames. It isn't super common and I'm not sure if other folks would have the same issue. But we would be interested in a solution to let us get a TIC area out of Skyline even when a few frames are dropped.

Is it possible to get some sort of fix in place for this?

Nick Shulman responded:  2023-06-22 10:53
I think you should convert the .d folders that you are having trouble with to mzML.

If you are using the msconvert.exe command line program, you can use the "scanNumber" filter to remove the spectra that you do not want.
(It might not be necessary to use that filter since it sounded like I was saying that msconvert was always skipping over the problematic spectra).

When Skyline extracts chromatograms from a .mzML file, you are supposed to get exactly the same results as if Skyline were to be using the original .d folder.
The only exception to this is if the Mass Analyzer settings at "Settings > Transition Settings > Full Scan" are "centroided".
The vendor centroiding algorithm can only be performed on the original raw data, so, if Skyline is going to need centroided data, then you should be sure to add the "peakPicking" filter to the msconvert.exe command line:
msconvert.exe --filter "peakPicking true 1-" AK_10.d
(The Skyline document you sent me had "TOF" as the mass analyzer, so you probably do not need to worry about this)

-- Nick