It sounds like the problem is that Skyline is not properly associating the chromatograms that are in your .raw file with the transitions in your Skyline document.

Can you send us your .raw file? I will take a look.
If your .raw file is less than 50MB, you can attach it to this support request.
Otherwise, you can upload it here:
https://skyline.ms/files.url

When Skyline reads chromatograms from an SRM .raw file, Skyline first groups the chromatograms together that have the same Q1 value. If the Q1 values of two chromatograms are different by even a tiny amount, then Skyline assumes they are for different peptides, and Skyline will have to choose which of the two groups best matches your peptide. This is often the problem when you see that each peptide is only getting one chromatogram in Skyline even though you intended there to be many.

When you are doing collision energy optimization, Skyline creates a method where the Q3 values differ by 0.01 m/z. The reason that Skyline does this is so that Skyline can tell the chromatograms apart. Skyline does not know how to read the collision energy from a .raw file, but Skyline assumes that whenever it sees Q3 values that differ by 0.01, they came from a method that varied the collision energy in the expected way.

We will probably be able to figure out what is going wrong when we see your .raw file.
-- Nick

Thank you for your response. Altis seems to iterate the transition by 0.001 for each CE step. Also the precusor is iterated for every 10th transition/CE step. Please see attached RAW files

If you have collision energy optimization turned on in Skyline, then, when you export a transition list or a method, you will get something where all of the transitions for a peptide have the same Q1 value, and the Q3 values for the transitions have steps that differ by 0.01.

Skyline only knows how to deal with sets of chromatograms that are exactly like that.

How did you create your method? Does Thermo Altis software have their own way of creating methods that test out a series of collision energy values? I don't think there is any way to get Skyline to work with data like that. (Actually, you could probably convert the .raw file to .mzML and do a bunch of search and replace to make it look like what Skyline would have produced, but that would be a lot of work).

Would it be possible for you to collect your data using a transition list that was exported by Skyline?
-- Nick

This was exported by skyline but Altis wouldn't run without further modifications. See below what Altis required to run. Show though this data was collected, I cant see it in Shyline

SRM SIC 431.91,611.841
SRM SIC 431.91,611.842
SRM SIC 431.91,611.843
SRM SIC 431.91,611.844
SRM SIC 431.91,611.845
SRM SIC 431.91,611.846
SRM SIC 431.91,611.847
SRM SIC 431.91,611.848
SRM SIC 431.91,611.849
SRM SIC 431.91,611.85
SRM SIC 431.911,547.321
SRM SIC 431.911,547.322
SRM SIC 431.911,547.323
SRM SIC 431.911,547.324
SRM SIC 431.911,547.325
SRM SIC 431.911,547.326
SRM SIC 431.911,547.327
SRM SIC 431.911,547.328
SRM SIC 431.911,547.329
SRM SIC 431.911,611.851
SRM SIC 431.912,497.781
SRM SIC 431.912,497.782
SRM SIC 431.912,497.783
SRM SIC 431.912,497.784
SRM SIC 431.912,497.785
SRM SIC 431.912,497.786
SRM SIC 431.912,497.787
SRM SIC 431.912,497.788
SRM SIC 431.912,547.33
SRM SIC 431.912,547.331
SRM SIC 431.913,462.261
SRM SIC 431.913,462.262
SRM SIC 431.913,462.263
SRM SIC 431.913,462.264
SRM SIC 431.913,462.265
SRM SIC 431.913,462.266
SRM SIC 431.913,462.267
SRM SIC 431.913,497.789
SRM SIC 431.913,497.79
SRM SIC 431.913,497.791
SRM SIC 431.914,462.268
SRM SIC 431.914,462.269
SRM SIC 431.914,462.27
SRM SIC 431.914,462.271

Another Skyline user mentioned this Altis behavior a year ago, but they seemed to be implying that it might have been fixed:
https://skyline.ms/announcements/home/support/thread.view?rowId=35176

I am going to ask the mass spectrometry experts in our lab whether they know anything about this.
-- Nick

I had seen that response, but to no avail....

The real problem is that the Q1 m/z value is changing for a single targeted precursor. Though this is similar to what Skyline does for Q3, Skyline does not support changes in Q1 and will always treat different Q1 values as different targets. It fundamentally, will not assign two sets of transitions with different Q1 m/z values to the same target in the Targets view. One set (the closest to the true target m/z) will win out over the others. This is why your Skyline document is generally showing matched chromatograms (green or red dots) for 1 or 2 transitions in your list.

Are you saying that the Thermo Altis forces a change in the Q1 value that is not in the transition list?

Skyline itself just introduces a compound name change every 10 transitions for the same Q1 like this:

Compound -- Precursor (m/z) -- Product (m/z)
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 649.677578
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 1148.605848
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 1035.521784
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 964.48467
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 836.426093
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 737.357679
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 666.320565
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 909.491432
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 844.970136
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 788.428104
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 731.886072
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 667.856783
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 700.351196
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 799.41961
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 912.503674
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 983.540788
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 1111.599366
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 1210.66778
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 705.877381
EELIQSVLAQVAEQFSR(+3)48 -- 649.677 -- 769.90667
EELIQSVLAQVAEQFSR(+3)49 -- 649.677 -- 843.440877
EELIQSVLAQVAEQFSR(+3)49 -- 649.677 -- 886.956891

The 48 and 49 are supposed to be .1 and .2, but there is a bug in the code, which I will fix. But, if you are saying that the Altis forces a change in the value 649.677 every 10 transitions, then this really is a problem for Skyline.

Skyline also introduces uniquifying naming for CE optimization by giving each CE "step" its own unique compound name like this:

Compound -- Precursor (m/z) -- Product (m/z)
EELIQSVLAQVAEQFSR(+3).-5 -- 649.677 -- 649.627578
EELIQSVLAQVAEQFSR(+3).-4 -- 649.677 -- 649.637578
EELIQSVLAQVAEQFSR(+3).-3 -- 649.677 -- 649.647578
EELIQSVLAQVAEQFSR(+3).-2 -- 649.677 -- 649.657578
EELIQSVLAQVAEQFSR(+3).-1 -- 649.677 -- 649.667578
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 649.677578
EELIQSVLAQVAEQFSR(+3).1 -- 649.677 -- 649.687578
EELIQSVLAQVAEQFSR(+3).2 -- 649.677 -- 649.697578
EELIQSVLAQVAEQFSR(+3).3 -- 649.677 -- 649.707578
EELIQSVLAQVAEQFSR(+3).4 -- 649.677 -- 649.717578
EELIQSVLAQVAEQFSR(+3).5 -- 649.677 -- 649.727578
EELIQSVLAQVAEQFSR(+3).-5 -- 649.677 -- 1148.555848
EELIQSVLAQVAEQFSR(+3).-4 -- 649.677 -- 1148.565848
EELIQSVLAQVAEQFSR(+3).-3 -- 649.677 -- 1148.575848
EELIQSVLAQVAEQFSR(+3).-2 -- 649.677 -- 1148.585848
EELIQSVLAQVAEQFSR(+3).-1 -- 649.677 -- 1148.595848
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 1148.605848
EELIQSVLAQVAEQFSR(+3).1 -- 649.677 -- 1148.615848
EELIQSVLAQVAEQFSR(+3).2 -- 649.677 -- 1148.625848
EELIQSVLAQVAEQFSR(+3).3 -- 649.677 -- 1148.635848
EELIQSVLAQVAEQFSR(+3).4 -- 649.677 -- 1148.645848
EELIQSVLAQVAEQFSR(+3).5 -- 649.677 -- 1148.655848
EELIQSVLAQVAEQFSR(+3).-5 -- 649.677 -- 1035.471784
EELIQSVLAQVAEQFSR(+3).-4 -- 649.677 -- 1035.481784
EELIQSVLAQVAEQFSR(+3).-3 -- 649.677 -- 1035.491784
EELIQSVLAQVAEQFSR(+3).-2 -- 649.677 -- 1035.501784
EELIQSVLAQVAEQFSR(+3).-1 -- 649.677 -- 1035.511784
EELIQSVLAQVAEQFSR(+3) -- 649.677 -- 1035.521784
EELIQSVLAQVAEQFSR(+3).1 -- 649.677 -- 1035.531784
EELIQSVLAQVAEQFSR(+3).2 -- 649.677 -- 1035.541784
EELIQSVLAQVAEQFSR(+3).3 -- 649.677 -- 1035.551784
EELIQSVLAQVAEQFSR(+3).4 -- 649.677 -- 1035.561784
EELIQSVLAQVAEQFSR(+3).5 -- 649.677 -- 1035.571784

But, again, if the Altis forces a change in precursor m/z every 10 transitions, then that is going to be a problem. We do rely on the instruments being able to park on the same precursor m/z while we vary the product m/z and CE.

This is in fact what Ive been told by Thermo, will confer with their tech folks again to confirm.

Just following up on this as I am quite stuck....Is there any way to change the tolerance of Q1 in skyline so we can elicit the CE values?

Avi

My understanding is that there was no reason for Q1 values to be changed.
It is true that the Altis cannot handle more than 10 transitions per compound, and it is for this reason that Skyline changes the number at the end of the compound name when Skyline exports the transition list.

If you need to get Skyline to work with the data that you have already collected, then I would recommend that you convert your .raw files to .mzML, and then do a search and replace in a text editor so that the Q1 values all end up being the same.

It sounds like you are saying that the Altis is not allowing you to have a method where the Q1 values are all the same. I will ask our mass spectrometry experts in our lab to add some comments to this thread since everything is apparently working for them.
-- Nick

ok. Would love to hear your MS experts view on this point. I have started the .mzML process though this is tedious....

Can you upload the transition list? I can try import into our Altis and see what the error message is.

--Eric

The raw files and skyline file are above in the thread

Avi,

Above, when you said "This was exported by skyline but Altis wouldn't run without further modifications", it looks like you gave us the transition list after you modified it to fix the error.

Can you give us the original transition list that caused the error on your Altis?
-- Nick

I am not getting an error. Rather Skyline fails to align the transitions from the Altis raw file because of the iterating Q1 values.

Hi Avi,
We are interested in understanding how your transitions ended up as they did in your RAW data file. We do not believe that a transition list from Skyline for the Thermo Altis would produce the SRM SIC values you have provided. So, if you can provide us what Skyline actually exported for your CE method, then we can have a look.

One plausible explanation I have is that you might have chosen simply "Thermo" as the target for your File > Export > Transition list, instead of "Thermo Quantiva" or "Thermo Altis" (added in the 4.2.0.19009 patch release to Skyline 4.2).

The Thermo Quantiva and Thermo Altis choices attempt to deal with the 10 transitions per compound limit by changing the compound names very slightly, without changing the precursor m/z values. When we look at your SRM SIC listings, we see the precursor m/z changing by 0.001, which is not something Skyline itself ever does. Nor is it something we can easily just add support for you, because it happened in the data you collected.

What we really need to know is how did those mass shifts occur, and can we help you to understand a CE optimization workflow on the Thermo Altis that does not require the shifts in precursor m/z, or is there truly a limitation on the Altis which we do not yet understand, which makes our existing solution, implemented for the Thermo Quantiva (on February, 2015) not work for you. I have to assume that in those 4+ intervening years, it has worked for some owners of at least the Thermo Quantiva and maybe the Altis, which we did not expect to change in this respect.

--Brendan

In summary, we need you to try to back-track through your steps from exporting a transition list from Skyline (we'd like to see that transition list) to setting up your .meth file for the Thermo Altis (interested in seeing that file as well).

So, if you can send us a CSV exported by Skyline and a .meth file used to run the instrument, those would be a great help in understanding what happened.

We exported from skyline just fine. The Thermo method editor will not take more than 10 transitions with the same Q1 value and requires that you change it. We added the 3rd and final digit to the Q1 value without which the method would not be accepted.

When I export from skyline, I can see the iterations to the product ion (11 transitions over 0.1 m/z). However the precursors all have the same m/z which Thermo method editor balks at after 10 transitions.

Are the compound names changing in your transition list? In our experience, changing the compound names and not the precursor m/z suffices to solve the error you are reporting from the Thermo method editor.

I just tried this on our Thermo Altis (running version 3.0 instrument software), and the Compound Name change worked just fine. I was able to get a .meth file with 20 transitions having the same precursor m/z, but two different compound names (10 transitions each). I did this using Skyline-daily and the recently fixed File > Export > Method for Thermo Altis, instead of File > Export > Transition List.

But, until shown otherwise, I have to think that you used something like File > Export > Transition List - "Thermo" and got all your transitions with the same Compound Name, which was fine for the Thermo Vantage or earlier, but not for Quantiva or Altis. It seems very slightly adjusting the precursor m/z (Q1) is one way to get the Thermo method editor to accept a method like this, but it is unfortunately not one that works with Skyline. We need the compound name to change and the precursor m/z to stay the same.