Changes for dealing with newer relatively complex Bruker DiaPASEF modes, e.g. "Diagonal" PASEF or "MiDia" PASEF… #3583
Conversation
…es, e.g. "Diagonal" PASEF or "MiDia" PASEF (which, significantly, has overlapping isolation ranges for its MS2 scans) The fundamental change is Skyline's use of the DiaFrameMsMsWindows table found in analysis.tdf. This information is now passed into the mzML model as a set of UserParams. Equipped with this information Skyline can now choose the ideal WindowGroup for each transition before starting chromaogram extraction. Formerly this was based on observing the data as it passed by, which pretty quickly settled on the proper window group but often meant a few early chhromatogram points pulled from the wrong window group. The observable effect is that the more correct approach tends to produce chromatograms that start slightly later than with the old code. One significant effect of this is that Skyline can determine which transitions simply do not fit any WindowGroup's combination of precursor isolation and ion mobility filtering. In these cases a message is written to the ImmediateWindow (or console, for commandline use) e.g. "No isolation window found in B_20231027_IO25x75_HeLa_800ng_35min_midiaPASEF_24x12_75ms_frag_Slot2-6_1_6699.d for precursor LLEDGEDFNLGDALDSSNSMQTIQK (m/z=1370,634536025 im=ccs530,301031483079/1,3173898204277Vs/cm^2/he/1/K0 (Vs/cm^2)/w0,087826)" Skyline requests Bruker DIA MS2 data be passed as entire frames in the 3-array [mz, intensity, ionMobility], omitting any scans in the frame that are not mentioned in the frame's DiaFrameMsMsWindows entry. Skyline can use the ion mobility values in MS2 frames as markers for precursor isolation range, so Skyline does not request the isolation range arrays ([mz, intensity, ionMobility, isoLow, isoHigh]) which are made available for MS2 frames. Next steps - try not sorting MS2 full frames on mz, instead make the inherently sorted IM dimension our primary when we have that IM<->Isolation mapping available
…'s a big data set, but if Bruker feels its a suitable benchmark then I'd prefer to be continuously evaluating performance and correctness rather than trying to trim it.
pwiz_tools/Skyline/Model/DocSettings/TransitionIonMobilityFiltering.cs
Outdated
Show resolved
Hide resolved
| { | ||
| foreach (var pair in doc.PeptidePrecursorPairs) | ||
| { | ||
| if (!results.TryLoadChromatogram(index, pair.NodePep, pair.NodeGroup, |
There was a problem hiding this comment.
Passing "index" in here means that this code is assuming that there is only one result file per Replicate.
You might want to rewrite this so that it has an outer loop that iterates of MeasuredResults.Chromatograms, and an inner loop which iterates over the MSDataFileInfos in that ChromatogramSet.
There was a problem hiding this comment.
I'll add a comment to this effect, thanks. As it's only debug code it's probably not worth the effort to make it 100% bulletproof against a relatively unusual condition.
There was a problem hiding this comment.
Looking more closely I do take your point, we could miss important differences and never know about it. I'll implement your suggestion, thanks.
make ResultsUtil.GetResultsTextForComparison() support multiple data files per replicate extra safety for IonMobilityFilter.ApplyOffset() in case of negative offsets
|
@chambm do you want to have a look at this before I merge? |
|
3 participants
… (which, significantly, has overlapping isolation ranges for its MS2 scans)
The fundamental change is Skyline's use of the DiaFrameMsMsWindows table found in analysis.tdf. This information is now passed into the mzML model as a set of UserParams.
Equipped with this information Skyline can now choose the ideal WindowGroup for each transition before starting chromaogram extraction. Formerly this was based on observing the data as it passed by, which pretty quickly settled on the proper window group but often meant a few early chhromatogram points pulled from the wrong window group. The observable effect is that the more correct approach tends to produce chromatograms that start slightly later than with the old code.
One significant effect of this is that Skyline can determine which transitions simply do not fit any WindowGroup's combination of precursor isolation and ion mobility filtering. In these cases a message is written to the ImmediateWindow (or console, for commandline use) e.g. "No isolation window found in B_20231027_IO25x75_HeLa_800ng_35min_midiaPASEF_24x12_75ms_frag_Slot2-6_1_6699.d for precursor LLEDGEDFNLGDALDSSNSMQTIQK (m/z=1370,634536025 im=ccs530,301031483079/1,3173898204277Vs/cm^2/he/1/K0 (Vs/cm^2)/w0,087826)"
Skyline requests Bruker DIA MS2 data be passed as entire frames in the 3-array [mz, intensity, ionMobility], omitting any scans in the frame that are not mentioned in the frame's DiaFrameMsMsWindows entry.
Skyline can use the ion mobility values in MS2 frames as markers for precursor isolation range, so Skyline does not request the optional isolation range arrays [mz, intensity, ionMobility, isoLow, isoHigh] - it just asks for [mz, intensity, ionMobility].
N.B. I tried not sorting MS2 full frames on mz, instead make the inherently sorted IM dimension our primary when we have that IM<->Isolation mapping available, but there was no performance benefit.