Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DIA pipeline quantifies peptides at wrong retention time #1233

Open
tomvaiuw opened this issue Aug 30, 2023 · 8 comments
Open

DIA pipeline quantifies peptides at wrong retention time #1233

tomvaiuw opened this issue Aug 30, 2023 · 8 comments

Comments

@tomvaiuw
Copy link

Hi,
We are running some data through DIA-SpecLib-Quant pipeline and we find that several peptides are quantified at wrong retention time (we check the chromatograms in Skyline) as shown in this correlation:
image

x-axis Skyline manually curated true retention time, y-axis - retention time reported in the diann-output.tsv
For example the major outlier (16min vs 20.5 min peak) - peptide LSPLGEEMR shows no peak at the 20.5 min -
image

I am not sure how to explain this and correct it.

Thanks,
Tomas
University of Washington

@anesvi
Copy link
Collaborator

anesvi commented Aug 30, 2023

I see you built the library from GPF files. Can you check that peptide in the corresponding GPF file. The retention time in the library comes from the MS2 scan that gave the best identification score. So the GPF file should have a strong signal at that retention time. Why is it missing at that RT in the DIA-Quant file, and observed in a different part of the chromatograph, I don't know. You can also try to annotate quant files as DIA, not DIA-quant. That way all files will be used for spectral library building and maybe you will get it with the right retention time.
Alexey

@tomvaiuw
Copy link
Author

tomvaiuw commented Aug 31, 2023 via email

@anesvi
Copy link
Collaborator

anesvi commented Aug 31, 2023

You should check PSM.tsv file. I will list all scans where the peptide was identified in GPF runs and with what scores. I believe the best probability one sets the RT shown in the library.

@tomvaiuw
Copy link
Author

tomvaiuw commented Aug 31, 2023 via email

@anesvi
Copy link
Collaborator

anesvi commented Aug 31, 2023

EasyPQP that builds the library does not trace peaks to determine the apex Rt. Yes, a better logic for selecting the RT would be helpful. Also remember that the precursor maybe identified in multiple files, so even if we reset the RT value to the Apex (which we can possibly do in MSFragger),there are still complications. We can discuss more with you if you have some suggestions, but it would not be an immediate fix. I hope there are just a few special cases like this.

@tomvaiuw
Copy link
Author

tomvaiuw commented Sep 12, 2023 via email

@anesvi
Copy link
Collaborator

anesvi commented Sep 12, 2023

Thanks! We will look into changing EasyPQP to make reported RT values better

@tomvaiuw
Copy link
Author

tomvaiuw commented Sep 19, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants