Peaks of light and heavy peptides have unequal peak boundaries

support
Peaks of light and heavy peptides have unequal peak boundaries fcsigloch  2020-10-22
 

Hi!

In an MRM experiment, I came across the problem that Skyline picks non-coeluting peaks for the light endogenous peptide and the heavy labelled reference peptide (screenshot attached). I never observed this behaviour in PRM data, where I am used to perfectly matching peak boundaries.
I could not determine a specific setting that caused this behaviour. Can I somehow force Skyline to choose the same peak boundaries for light and heavy trace?

Also, I tried to train a default or mProphet model to improve the peak picking. Training the model worked, but when I want to apply it to the data, I get the following error message:

---------------------------
Skyline
---------------------------
Failed attempting to reintegrate peaks.
The index 6 must be between 0 and 2
---------------------------
OK More Info
---------------------------
System.Reflection.TargetInvocationException: The index 6 must be between 0 and 2 ---> System.Reflection.TargetInvocationException: The index 6 must be between 0 and 2 ---> System.IndexOutOfRangeException: The index 6 must be between 0 and 2
   bei pwiz.Skyline.Model.Results.ChromatogramInfo.GetPeak(Int32 peakIndex) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\Results\ChromHeaderInfo.cs:Zeile 2773.
   bei pwiz.Skyline.Model.TransitionGroupDocNode.UpdateResults(SrmSettings settingsNew, SrmSettingsDiff diff, PeptideDocNode nodePep, TransitionGroupDocNode nodePrevious) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\TransitionGroupDocNode.cs:Zeile 1487.
   bei pwiz.Skyline.Model.TransitionGroupDocNode.ChangeSettings(SrmSettings settingsNew, PeptideDocNode nodePep, ExplicitMods mods, SrmSettingsDiff diff) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\TransitionGroupDocNode.cs:Zeile 1116.
   bei pwiz.Skyline.Model.PeptideDocNode.ChangeSettings(SrmSettings settingsNew, SrmSettingsDiff diff, Boolean recurse) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\PeptideDocNode.cs:Zeile 979.
   bei pwiz.Skyline.Model.SrmDocument.<>c__DisplayClass142_5.<ChangeSettingsInternal>b__7(Int32 i) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\SrmDocument.cs:Zeile 1080.
   bei pwiz.Common.SystemUtil.ProducerConsumerWorker`2.Consume(Object threadIndex) in C:\proj\skyline_20_2_x64\pwiz_tools\Shared\Common\SystemUtil\ProducerConsumerWorker.cs:Zeile 186.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei pwiz.Skyline.Util.Helpers.WrapAndThrowException(Exception x) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Util\Util.cs:Zeile 1944.
   bei pwiz.Skyline.Util.ParallelEx.LoopWithExceptionHandling(Action loop, Action`1 catchClause) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Util\Util.cs:Zeile 2246.
   bei pwiz.Skyline.Util.ParallelEx.For(Int32 fromInclusive, Int32 toExclusive, Action`1 body, Action`1 catchClause, Nullable`1 maxThreads) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Util\Util.cs:Zeile 2190.
   bei pwiz.Skyline.Model.SrmDocument.ChangeSettingsInternal(SrmSettings settingsNew, SrmSettingsChangeMonitor progressMonitor) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\SrmDocument.cs:Zeile 1068.
   bei pwiz.Skyline.Model.MProphetResultsHandler.ChangePeaks(IProgressMonitor progressMonitor) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\MProphetResultsHandler.cs:Zeile 172.
   bei pwiz.Skyline.EditUI.ReintegrateDlg.<>c__DisplayClass12_1.<OkDialog>b__1(IProgressMonitor pm) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\EditUI\ReintegrateDlg.cs:Zeile 133.
   bei pwiz.Skyline.Controls.LongWaitDlg.RunWork(Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 254.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei pwiz.Skyline.Util.Helpers.WrapAndThrowException(Exception x) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Util\Util.cs:Zeile 1944.
   bei pwiz.Skyline.Controls.LongWaitDlg.PerformWork(Control parent, Int32 delayMillis, Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 202.
   bei pwiz.Skyline.Controls.LongWaitDlg.PerformWork(Control parent, Int32 delayMillis, Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 140.
   bei pwiz.Skyline.EditUI.ReintegrateDlg.OkDialog() in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\EditUI\ReintegrateDlg.cs:Zeile 135.
---------------------------

Thanks for your help!

 
 
Nick Shulman responded:  2020-10-22
I think this error happens if the same peptide appears in your Skyline document more than once, and those different instances of the peptide each have a different set of charge states or other precursors under them.

Does the peptide that is giving you problems appear multiple times in the document? If so, I think you can fix this behavior by removing all except for one of those peptides. (You can use the menu item "Refine > Remove Repeated Peptides" for this). After that you can do "Edit > Manage Results > Rescore" and I think every thing will be fixed.

Normally repeated peptides are not a problem for Skyline. However, if some of those peptides have a different set of precursors under them, then Skyline can get very confused during reintegration.

If you would like you could send us your Skyline document and I could make sure that that's what's going on.

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

If that .zip file is less than 50MB you can attach it to this support request.
Otherwise you can upload it here:
https://skyline.ms/files.url

Here is a support request where someone else encountered this same error:
https://skyline.ms/announcements/home/support/thread.view?rowId=27885

-- Nick
 
fcsigloch responded:  2020-10-22

Hi Nick!

Thanks for your very quick response! Unfortunately, your suggestions did not solve the problem.
Here is what I tried:

  1. I searched for repeated peptides and also had a closer look at precursors and transitions. None of these is doubled, though some are pretty close in m/z (see attached R Notebook). I do not know if this could lead to problems. To be sure, I used Refine > Remove Repeated Peptides anyways.
  2. I then tried Edit > Manage Results > Rescore, but it did not help.

I do not know exactly how the file was built, I got it from a collaborator. He might have been using an old Skyline version. I was using the current version 20.2.0.286.
Because it is a collaborators file, I would not like to upload it here. Could I send it to you personally?

 
fcsigloch responded:  2020-10-23

My collaborators agreed to upload the file. It is Corona-related research, so speed is everything!

 
fcsigloch responded:  2020-10-23

The file was originally created in Skyline version 20.1.
Manual correction of peaks will not help, because the protocol is going to be run on a high number of samples.

For an example of the described behavior, check the Peptide LNQLESK in the files eSwab_PolyQuant_2ng_3 and _4.
The problem is also clearly visible in the RT replicate comparison, see attached screenshot.

 
Nick Shulman responded:  2020-10-23
I see that this is an SRM experiment.

One thing that I noticed is that some of your precursors have only one chromatogram under them.
For instance, in the peptide RGPEQTQGNFGDQELIR, the heavy transition G [y10] - 1163.5250+ does not have a chromatogram in any of your replicates, so the only chromatogram it has is G [y7] - 841.4040+

I think I remember something about Skyline treating precursors with only one matching SRM chromatogram differently in some way when it comes to peak picking. I cannot remember exactly what ends up being different, but that might be the cause of the strange behavior that you are seeing.

If you send me a couple of your .raw files I might be able to give you more details about exactly what is going wrong.
-- Nick
 
bart van puyvelde responded:  2020-10-25
Hi Nick,

In attachment you can find some .Raw files.
Let me know if you would need anything more.

Best,
Bart
 
Nick Shulman responded:  2020-10-25
Bart,

Thank you for sending me your Waters raw SRM data files.
I see that many of the heavy precursors in your Skyline document have two or more transitions, but there was only one transition collected for them in the raw data file.
For instance, the peptide LNQLESK has a heavy precursor with m/z 421.2173 and transitions 611.3093 and 481.2567.
In your raw data files, the only chromatogram which matches that is Q1=421.236 Q3=651.39.

If a precursor in your Skyline document has more than one transition, but only has one matching chromatogram in the raw file, it gets treated differently in terms of peak finding. This behavior is probably a bug that we should fix, but it will probably be tricky for us to fix.
You can work around this behavior by removing the transitions from your Skyline document which have no matching chromatograms. I have done this for you in the attached .sky.zip file.

After you have removed all of transitions that have no chromatograms, you can tell Skyline to do the peak finding again by doing:
Edit > Manage Results > Rescore
If you want Skyline to choose peaks even for the ones where you have manually adjusted the peak boundaries you can do:
Refine > Reintegrate
check the "Overwrite manual integration" and hit "OK".

You might find it a little tricky to delete the necessary heavy transitions from your Skyline document. If you delete them by selecting them in the Targets tree, Skyline will also delete the corresponding transition from the light precursor as well.
One way to delete the heavy transitions that you want is to right-click on the heavy precursor and choose "Pick Children", and make sure the box "Synchronize isotope label types" is unchecked, and then uncheck the boxes next to the transitions that you want to delete.

The other way to delete heavy transitions without deleting the light transitions would be to use the Document Grid.

I hope these workarounds enable you to analyze your data. I think you might have made a mistake with your SRM method, and you might have intended to collect more transitions for your heavy standards.
-- Nick
 
fcsigloch responded:  2020-10-26

Hi Nick!
Thanks a lot for your great support! Removing the empty transitions indeed did the trick - the light and heavy peaks are aligned in RT. Only one transition (562.3017+++) of the peptide DGIIWVATEGALNTPK still seems to be not aligned. This one is the only peptide with two charge states measured.
Also, the error message for applying a trained Default model for peak picking is gone, the model can now be trained and applied to the data. However, mProphet this time throws an error already at the training step. The error is a bit strange, because it reports 1008 decoys, although I trained on second best peaks. There are no decoys in the dataset:

---------------------------
Skyline
---------------------------
Failed training the model:
Insufficient target peaks (0 with 1008 decoys) detected at 2% FDR to continue training.
---------------------------
OK More Info
---------------------------
System.IO.InvalidDataException: Insufficient target peaks (0 with 1008 decoys) detected at 2% FDR to continue training. ---> System.IO.InvalidDataException: Insufficient target peaks (0 with 1008 decoys) detected at 2% FDR to continue training.
   bei pwiz.Skyline.Model.Results.Scoring.MProphetPeakScoringModel.CalculateWeights(String documentPath, ScoredGroupPeaksSet targetTransitionGroups, ScoredGroupPeaksSet decoyTransitionGroups, Boolean includeSecondBest, Boolean nonParametricPValues, Double qValueCutoff, Double[] weights, Double& decoyMean, Double& decoyStdev, Boolean& colinearWarning) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\Results\Scoring\MProphetScoringModel.cs:Zeile 423.
   bei pwiz.Skyline.Model.Results.Scoring.MProphetPeakScoringModel.<>c__DisplayClass23_0.<Train>b__0(MProphetPeakScoringModel im) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\Results\Scoring\MProphetScoringModel.cs:Zeile 267.
   bei pwiz.Common.SystemUtil.Immutable.ChangeProp[TIm](TIm immutable, SetLambda`1 set) in C:\proj\skyline_20_2_x64\pwiz_tools\Shared\Common\SystemUtil\Immutable.cs:Zeile 201.
   bei pwiz.Skyline.Model.Results.Scoring.MProphetPeakScoringModel.Train(IList`1 targetsIn, IList`1 decoysIn, TargetDecoyGenerator targetDecoyGenerator, LinearModelParams initParameters, IList`1 cutoffs, Nullable`1 iterations, Boolean includeSecondBest, Boolean preTrain, IProgressMonitor progressMonitor, String documentPath) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Model\Results\Scoring\MProphetScoringModel.cs:Zeile 204.
   bei pwiz.Skyline.SettingsUI.EditPeakScoringModelDlg.<>c__DisplayClass38_0.<TrainModel>b__4(IProgressMonitor progressMonitor) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\SettingsUI\EditPeakScoringModelDlg.cs:Zeile 270.
   bei pwiz.Skyline.Controls.LongWaitDlg.RunWork(Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 254.
   --- Ende der internen Ausnahmestapelüberwachung ---
   bei pwiz.Skyline.Util.Helpers.WrapAndThrowException(Exception x) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Util\Util.cs:Zeile 1940.
   bei pwiz.Skyline.Controls.LongWaitDlg.PerformWork(Control parent, Int32 delayMillis, Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 202.
   bei pwiz.Skyline.Controls.LongWaitDlg.PerformWork(Control parent, Int32 delayMillis, Action`1 performWork) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\Controls\LongWaitDlg.cs:Zeile 140.
   bei pwiz.Skyline.SettingsUI.EditPeakScoringModelDlg.TrainModel(Boolean suppressWeights) in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\SettingsUI\EditPeakScoringModelDlg.cs:Zeile 273.
   bei pwiz.Skyline.SettingsUI.EditPeakScoringModelDlg.TrainModelClick() in C:\proj\skyline_20_2_x64\pwiz_tools\Skyline\SettingsUI\EditPeakScoringModelDlg.cs:Zeile 192.
---------------------------

 
Nick Shulman responded:  2020-10-26
When you choose to use "second best peaks" for training your model, those second best peaks become the "decoys" that are referred to in your error message.

I believe that if you were collecting data for more transitions in your heavy peptides that Skyline would have no trouble picking the correct peaks without you even having to train a model (that is, by using the "Default" peak picking model which Skyline always uses the first time for picking peaks).

You have "heavy" specified as your Internal Standard at:
Settings > Peptide Settings > Modifications

Skyline assumes that your Internal Standard will be easy to find in each of your replicates, whereas the light peptide may or may not be present depending on biological or experimental conditions. When you have an internal standard specified, Skyline effectively only looks for peaks in the heavy chromatograms. Since you are only monitoring one transition for each heavy precursor, Skyline is going to pick the wrong peak a lot of the time. You can easily see that Skyline has picked the wrong peak, because you are able to look at the light and heavy chromatograms, but Skyline does not think it should be looking at the light chromatograms because heavy is the internal standard.

I think you will find that the peak picking would improve if you were to go to "Settings > Peptide Settings > Modifications" and change "Internal Standard Type" to "None" (you would also need to do "Edit > Manage Results > Rescore" in order to see the effect). If you did that, then Skyline would be looking at all of the chromatograms in order to do peak picking.

However, the better thing to do would be to monitor more transitions for each of your heavy precursors.

-- Nick