Spectral library corruption

Spectral library corruption jfoe  2023-07-05 06:03

Dear Skyline Team,

I have recently updated to (841287d47) and have just noticed that I have by now corrupted several of my spectral libraries which is a critical problem for me now.
I am doing a workflow where I create my spectral libraries manually in skyline. I typically have several files loaded and select the best quality peak only, such that it gets included in my spectral library.

When I create spectral libraries like this (Export -> Spectral Library) and then inspect it in skyline, I get "Failure loading spectrum. Library may be corrupted.".
What I found by now is that this seems to occur specifically when the peak for a precursor is not selected in the last results file.

I am attaching an example skyline file and the spectral library that I exported from it. Loading the spectral library with skyline then gives the error text as illustrated in the .png that I am also attaching.

I would be very grateful for your help with this.

Nick Shulman responded:  2023-07-05 07:15

I do not know how your document got this way, but you can tell something has gone wrong if you create a Report in the Document Grid that includes the column called "Best Replicate".
(If you would like to learn more about the Document Grid you can look at the Custom Reports tutorial)

The "Best Replicate" column is supposed to tell you which replicate has the best scoring peak selected, but, as you can see from the attached screenshot, Skyline thinks that the best replicate is the last replicate. That replicate has an area is "#N/A" indicating that the peak was removed.

Do you have any idea how your document may have gotten this way? It looks like the peak boundaries might have been imported using perhaps the "File > Import > Peak Boundaries".

If you did import peak boundaries, could you send me the peak boundaries file CSV file that you imported?
Also, if you have a copy of your document as it existed before the peaks were removed, that would be helpful too.
Files which are less than 50MB can be attached to this support request. You can upload larger files here:

I think the problem is that when the peaks were removed, Skyline should have recomputed which was the "Best Replicate". As it was, when Skyline exported the spectral library, no spectrum in the .blib file was marked as the best replicate, which caused problems when Skyline wanted to show you the graph that is displayed in the Library Match window.
-- Nick

jfoe responded:  2023-07-05 07:42

Dear Nick,

I did indeed use the Peak Boundaries import. So I think that is a great clue.
I am attaching the "Peak Boundaries.csv" that I imported.

The Peak Boundaries.csv was actually also created with the same skyline document. The reason I am doing this workflow of exporting boundaries and reimporting them has to do with the long standing issue of transition areas not being recalculated on reimport of results.
I had reported this earlier (https://skyline.ms/announcements/home/support/thread.view?rowId=52333) and you thankfully responded and worked out some fixes but eventually it didn't completely resolve my issues.
Ever since, I have frequently been adjusting to e.g. use additional transitions and then to get all peaks to update, I was exporting "Peak Boundaries" and then importing those right away. This was a very effective fix for me.

Comparing to some other peak boundaries files, I think they always had the same format. So the recent change would then likely have to do with how the import works.


jfoe responded:  2023-07-05 07:45

I also just realized the Peak Boundaries I uploaded are from the complete document as opposed to the minimal example that I uploaded earlier. I think that won't affect the conclusions though.

Nick Shulman responded:  2023-07-05 08:02
The behavior that you were working around where transition peak areas are not recalculated when you change extraction parameters and reimport was supposed to have been fixed in October 2021. If you find that you are still having to do your workaround then you should send me your Skyline document and your .raw files and I will figure out what is not working correctly.

In the meantime I'll try to figure out what went wrong with the original document and the peak boundaries file.
-- Nick
jfoe responded:  2023-07-06 00:04
Dear Nick,

I did some testing and realized you did indeed fully correct my last minimal example, which was fixing a majority of the problem cases for me and which I was very happy about.
I now tried to adapt that example to show a further case.
To get this going quickly I manually edited the skyline xml (new transition) but I think the document is in a valid state.
I am uploading the skyline document zip and the sample.raw

What I am trying to show is that, if a new transition is activated (via pick children), for which no data has been extracted yet, a data reimport will once again fail to trigger an update of the peak areas.
The document is in the following state: 2 transitions are active. One has outdated information because I adapted the extraction from 1ppm tolerance to 1000ppm. The second one has no information yet, because I just activated it and there was no data.
Note the transition areas: 17608, #N/A
Now reimport the sample.raw.
New transition areas: 7253, #N/A

For transition 696.0, your fix correctly triggered the update.
The XIC now also shows the trace for transition 303.4 but there is no area. Manually adjusting the peak limits fixes the calculation.
This was often a document-wide issue for me with many precursors affected. The only reliable solution I had was to export and reimport peak boundaries.

I hope this helps.

Nick Shulman responded:  2023-07-06 06:20

You attached a ".sky.view" file to your last post. I think you meant to attach the ".sky.zip" file that you would have created using the "File > Share" menu item in Skyline.
Can you send me a .sky.zip file?

-- Nick
jfoe responded:  2023-07-06 06:26
Yes. Thanks for your efforts already. I was able to edit the post and fix the file.
jfoe responded:  2023-07-26 02:59
Dear Nick,

As it has been some time I was wondering if you already had the chance to reproduce the issue. Maybe I can find some workarounds still if it is unlikely to get any kind of hotfix.
Thanks for the help!