iRT peak pickinpicking wrong peak of some replicates)

iRT peak pickinpicking wrong peak of some replicates) boycea  2021-05-03

After setting up our iRT predicted calculator, chrom libraries, replicates uploaded, and reintegrating by the mProphey peak scoring model and 0.01 significant q values, we noticed that some peptides don't have the same, nor correct peaks picked automatically among all their replicates. On top of that, those incorrect peaks had higher ppm (>10), lower dotp (<0.7), and further from the predicted time than other peaks that seems like they should be automatically choosing (on predicted RT, dotp=0.99, ppm<1). Is there a filter or refinement in skyline that can automatically pick the peaks that seem more likely based on certain dotp, ppm, and RT thresholds, and consistently across all replicates of all peptides? Also, more specifically, is there a filter for eliminating or reintegrating peptides that don't have peaks within a certain ppm threshold. I have a document with a couple of examples, if needed.

In the example provided, for gene CLU, peptide ASSII, most replicates chosen is the small peak in the middle of 3 at RT ~25.3, dotp >0.98, and ppm<10. However, other replicates (e.g. 1, 13, 27), with less ideal ppm, dotp, and RT peaks (the one on the right, ~RT 25.5) were chosen, and when we manually integrated the middle peak in the those replicates, it gave us favorable ppm and dotp like the rest. Is there further refinement we can so that more peptides will have more consistent peaks chosen among all the replicates without having to go through each of them?



Nick Shulman responded:  2021-05-03
Can you send us your Skyline document?

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 is less than 50MB you can attach it to this support request.

Otherwise, you can upload it here:

-- Nick
Nick Shulman responded:  2021-05-04
In the replicate "01" for the peptide "R.ASSIIDELFQDR.F", the reason that Skyline is picking the peak at 25.6 instead of the peak at 25.3 is that the peak at 25.3 has a very bad "Co-elution count" score.
You can see whether Skyline considers a transition to be coeluting by adding the "Coeluting" column to the Transition Results report in the Document Grid.
All of the transitions for the peak at 25.3 are considered to be not coeluting. If you look at the chromatograms, they certainly look like they are coeluting with each other beautifully.
This must mean that when Skyline extracted chromatograms there were other transitions in your document than the ones that we are seeing now. You should tell Skyline to rescore all of the peaks based on the set of transitions that you have now.

To do that, first go to:
Edit > Manage Results > Minimize
and choose "Remove unused chromatograms" and then push either "Minimize in place" or "Minimize and save as".
(the .skyd file will then shrink from 10GB to 600MB)

Then, go to:
Edit > Manage Results > Rescore

Unfortunately, after I did all that, Skyline still did not find the peak that you would have wanted. For some reason, Skyline chooses a peak that goes from 24.6 to 25.41, because Skyline seems to be merging two peaks that were next to each other.

In the next version of Skyline I am supposed to make it a lot easier for to compare the scores that the candidate peaks got, so that you can see why Skyline picked one peak instead of another. For now, the only way to figure something like that out is to use "File > Export > Mprophet Features" to get all of the scores, and then use Excel to multiply those scores by the weights from the peak scoring model and see which weighted feature score is having the biggest effect on the combined score.
-- Nick