Issue 124: Skyline saved file won't open probably because replicates rearranged

issues
Status:closed
Assigned To:Guest
Type:Defect
Area:Skyline
Priority:3
Milestone:1.2
Opened:2011-12-07 by Nathan Manes
Changed:2012-02-24 by Brendan MacLean
Resolved:2012-02-24 by Brendan MacLean
Resolution:Fixed
Closed:2012-02-24 by Brendan MacLean
2011-12-07 Nathan Manes
Title»Skyline saved file won't open probably because replicates rearranged
Assigned To»Brendan MacLean
Type»Defect
Area»Skyline
Priority»3
Milestone»1.2
Skyline v1.1.0.2905
I suggest giving this issue high priority. It didn't cause me much harm (I'll redo ~4h of manually inspecting results). It could cause other users major loss of work/time (especially if those users didn't make incremental backups).

Problem Description:
A .sky saved file (saved by Skyline and unaltered) won't open (see attached screen shot).

Background and likely source of bug:
I imported 7 replicates (each was from 4 Thermo .RAW files, 28 files total).
I saved the file (and made a backup - it's fine).
I began to manually edit the results (reassigning peaks and removing peaks).
I decided to rearrange the sets of results ("Edit" -> "Manage Results..." -> move up/down).
I did some more manual editing, saved the file, and was unable to reopen the saved file the next day.
The error message pointed to the following lines within the .sky file:

      <peptide_results>
        <peptide_result replicate="MTCa" file="MTCa_f1" peak_count_ratio="1" retention_time="44.26768" />
        <peptide_result replicate="MTCb" file="MTCb_f1" peak_count_ratio="1" retention_time="44.23829" />
        <peptide_result replicate="MTCc" file="MTCc_f1" peak_count_ratio="1" retention_time="44.26767" />
        <peptide_result replicate="MTCd" file="MTCd_f-1" peak_count_ratio="0" />
        <peptide_result replicate="MTCd" file="MTCd_f2" peak_count_ratio="0" />
        <peptide_result replicate="MTCe" file="MTCe_f-1" peak_count_ratio="0" />
        <peptide_result replicate="MTCe" file="MTCe_f2" peak_count_ratio="0.5" retention_time="44.62411" />
        <peptide_result replicate="RMTC1a" file="RMTC1a_f-1" peak_count_ratio="0" />
        <peptide_result replicate="RMTC1a" file="RMTC1a_f2" peak_count_ratio="0" />
        <peptide_result replicate="RMTC1b" file="RMTC1b_f-1" peak_count_ratio="0" />
        <peptide_result replicate="RMTC1b" file="RMTC1b_f2" peak_count_ratio="0" />
      </peptide_results>

I notice 2 possible problems. First, multiple lines are here for the same replicate (is this ever normal behavior?). Second, each <replicate> has a file ID of the form <replicate>_f# where # is 0, 1, 2, 3. My guess is that rearranging the replicates messed up the file ID's and the resulting #'s became -1, 0, 1, 2 (at least for some of the results). I suspect that you're accidentally subtracting 1 from the wrong integer variable. I see other examples of file ID #'s equal to -1 within the .sky file. I haven't attempted to reproduce the error so it's possible that it originated from something else or is somehow more complex. If you want me to try, let me know (nathan.manes@nih.gov), and also I can send you the .sky files.
 
 Skyline File Error 2011-12-07.png

2011-12-08 Brendan MacLean
Okay, I have figured it out. Thanks for sending your document, Nathan, and steps to reproduce.

It takes a special kind of document to encounter this issue. At the very least it is most likely to happen in a document like yours where a lot of transitions did not get integrated (red dots) for your RMTC1 replicates. I have a fix, and I made the failure case more robust also. Skyline now runs a check on the document after Manage Results is performed to make sure it is internally consistent. If not, Skyline rejects the change, and the user gets an error message.

Of course, this should never happen, and hopefully it won't after my fix, but at least with this check the attempt to make the change will just fail, rather than making it all the way to corrupting your document on save.

Since I am planning on releasing v1.2 very soon, I will just implement these fixes in the v1.2 code, and you will get them when you upgrade to v1.2, probably the fastest path to a fix anyway.

2012-02-24 Brendan MacLean
resolve as Fixed
Statusopen»resolved
Assigned ToBrendan MacLean»Nathan Manes
This fix was released with v1.2.

2012-02-24 Brendan MacLean
close
Statusresolved»closed
Assigned ToNathan Manes»Guest