Issue 458: MRM Chromatogram not Processed

issues
Status:closed
Assigned To:Guest
Type:Defect
Area:Skyline
Priority:3
Milestone: 
Opened:2016-02-12 by Olivier Gingras
Changed:2017-08-31 by Brendan MacLean
Resolved:2017-08-31 by Brendan MacLean
Resolution:Fixed
Closed:2017-08-31 by Brendan MacLean
2016-02-12 Olivier Gingras
Title»MRM Chromatogram not Processed
Assigned To»Brendan MacLean
Type»Defect
Area»Skyline
Priority»3
We have recently experienced the following issue using Skyline-64_3_5_0_9319 (unplugged) and scheduled MRM data acquired using a AB/Sciex 5500 QTRAP.

Our MRM Method contains 2414 scheduled transitions. When importing acquired data into Skyline, we could not get the chromatograms to load for 2 of the transitions (both from the same precursor). The chromatogram windows stays at "Chromatogram information not available" for these 2. The data for these 2 transitions can be seen correctly using AB/Sciex Analyst software.

The problematic transitions have the following m/z:
636.6581 => 594.3234 (rounded to 636.66 => 594.3 in the QTRAP method)
636.6581 => 537.3019 (rounded to 636.66 => 537.3 in the QTRAP method)

Our Method Match tolerance (m/z) was set to 0.2 within the Skyline Transition Settings.

I'm not entirely certain what is so special about those 2 transitions for them not to get loaded, but within our method, I found 2 other transitions for some other peptide having close-by Q1 m/z and identical Q3 m/z, but scheduled much later in RT (27 min vs 10 min) :
636.34 => 594.3
636.34 => 537.3

Yet in theory, the difference in Q1 m/z is higher than the method match tolerance set, so it should not generate any confusion. However, it seems to generate some sort of confusion because the chromatograms loaded for the other peptide (precursor 636.34) seems to extend to 10 minutes instead of being just the window around 27 minutes ( see image attached)

Having never encountered this issue before, I tried the previous version of Skyline we were using (Skyline-64_3_1_0_7382) and indeed, the chromatograms for precursor 636.66 could be loaded correctly (see image).






 


2017-08-31 Brendan MacLean
resolve as Fixed
Statusopen»resolved
Hope we got more information and fixed this one through some other communication mechanism. It is now pretty old and unlikely the necessary files are still around to reproduce.

2017-08-31 Brendan MacLean
close
Statusresolved»closed
Assigned ToBrendan MacLean»Guest