For some reason, the .blib file in that .sky.zip that you have attached only contains one peptide ("DVPPLSETEATPVPIK").
That library does not contain the peptide that you seem to be asking about ("ELWETLHQLEIDK").

I wonder if something went wrong when you did "File > Share".

Can you try doing "File > Share" again, and this time choose "Complete"?
(When you choose "Minimal", Skyline removes peptides from the library that Skyline thinks are not in the document. That might be the cause of your library having only one peptide in it-- I will try to figure out whether anything in this area is not working correctly).

It sounds like you are asking why there is no signal for the Y11 transition of the peptide "ELWETLHQLEIDK". Can you send us that raw file ("20170926_HV_DMD_PRMtest_iso1b.raw").

You can upload those files here:
https://skyline.ms/files.url

Here is the complete share file and also the raw file.

It looks like the files were not added here, but I managed to add them to the support file share page.

I think I see what you are saying.
In your spectral library, for the charge 3 peptide "ELWETLHQLEIDK+++", the best spectrum came from retention time 64.65 in the file "20170916_DMD_HV_shotgun_r2".
That spectrum has a nice peak at the y11+ m/z of 1419.736783
However, the chromatogram that was extracted for that transition has zero intensity along the entire length of the chromatogram.
(I've attached a screenshot)

I am not sure what is going wrong. Can you send me the file "20170916_DMD_HV_shotgun_r2.raw"?

I can't download this file, because I am on an airplane, but one possible explanation for this is a difference in the Transition Settings - Library tab field of Ion match tolerance (default 0.5) and the Transition Settings - Full-Scan tab field for MS/MS extraction range. That is if you left the Ion match tolerance at 0.5, but you are using a high-res mass spec and you extract at say 20 ppm for Centroided or say 20,000 resolving power for profile data, then Skyline will annotate peaks in the spectra, which do not really match.

If this is your case, an Ion match tolerance of 0.05 is a much better (and more typical choice), that won't completely get rid of the effect, since 0.05 and 20 ppm do not match exactly, but it will improve it greatly. The last time this came up, I seriously considered adding a checkbox below Ion match tolerance that would cause it to match exactly the extraction parameter from the Full-Scan tab, or at least a way to switch the field into a PPM tolerance.

That is my guess without being able to see the file. If you think that does not explain the problem, I will look more closely tomorrow when I get back to higher speed network access.

Thanks for using Skyline and posting this question.

--Brendan

Not that you can zoom way into the spectrum viewer to see the observed m/z of the peak on the x-axis to very high precision, or you can right-click the graph and check both "Observed m/z Values" and "Ion m/z Values" and then compare the two for Y11. If the difference is greater than 0.05, then the problem is the Ion match tolerance, as I have suggested.

Nick, I have now uploaded also the shotgun raw file.

Brendan, I took your advice about the ion match tolerance and reimported the files, but it didn't change anything. Probably because there was no difference in the observed and ion m/z values (check the added picture).

The spectrum in your spectral library looks different from what I see in the .raw file.
The time and scan ID match up (RT: 64.65 and ScanId: 20273) so it seems likely that I am looking at the correct scan in the correct file.

Is it possible that someone hand-edited your msms.txt file and put a different set of mzs and intensities in there?

Yes, I understand your confusion as I couldn't match the spectra either. I'm pretty confident that no one has modified the msms file that was used for the library. However, I'll run the MaxQuant search again and build the library again as well to make sure that this did not happen.

Ah. I missed that this was a library from a msms.txt. Please check the raw spectrum compared with the spectrum reported by MaxQuant. Juergen and I have exchanged emails about this a number of times, but I am not completely confident this issue was ever fixed. I will check again.

MaxQuant originally (and maybe still) performed spectrum "deconvolution" to make all ion matching peaks singly-charged. If this is still the case in the version you are using, whether because it never got fixed or you are using an older version, then that could mean that the peak you are seeing as y11+ (1419.736783) was actually y11++ in the original spectrum and it just got "deconvoluted" to where you see it now.

So, check the raw spectrum and compare it closely to the spectrum reported by MaxQuant in the msms.txt. I expect the raw spectrum in your original mass spect data file will agree with Skyline and you will find the peak currently reported as y11+ at y11++. You could also target y11++ in Skyline and see if you get the signal on it that you are currently expecting on y11+.

--Brendan

It's good to hear that you're aware of the problem and it looks to be the case here as well. Indeed there seems to be 710 m/z peak instead of the 1419 m/z peak. I'm using MaxQuant version 1.5.6.5, the newest one is 1.6.0.16. I'll try with this version soon and let you know if something has changed there. For now I can just manually remove the messed up fragments as the data set is not too big.

I have now gone through more of the data and I realised that the problem is actually worse than it seemed and in most of the cases it affects the longer (more specific) fragments that have double charge. So do you have any good suggestions how to go around that problem?

Could you post this to MaxQuant support? I have passed along your comments to Juergen, but I have been requesting a fix for this for a long time. It may be more persuasive coming from a MaxQuant user with real pain because of this deconvolution processing.

Thanks for digging into the details.

--Brendan

I'm not really getting any response back from MaxQuant. How do you search your .raw files for library build then if I may ask?

Unfortunately, I haven't gotten a response back yet either. Maybe they are busy with something. Our lab frequently uses Comet (formerly UW SEQUEST), because we have Jimmy Eng nearby to work with. But, lots of other tools work. Skyline supports 20+ different search pipelines.

https://skyline.ms/wiki/home/software/Skyline/page.view?name=building_spectral_libraries

We have even had pretty good luck with MaxQuant, but it does have this one issue. In larger experiments, it doesn't seem to have had a noticeable negative impact. Though, of course, we haven't been able to test against a MaxQuant with the issue fixed.

Hope this helps. Good luck with your spectral library building.