Hi Victor,

I can't think of any straightforward way to achieve this - Skyline assumes that your chromatography contains a single elution of any given molecule (which is, after all, the point of chromatography - to separate molecules of similar mass before they enter the mass spec).

I suppose you'd have to set up a second precursor+fragments set and explicit RT (and a slightly different name, so Skyline can tell them apart) and do a bit of postprocessing on the results.

Of course multiple elutions do happen, so I suppose you could make a case for Skyline combining them in the absence of any other explanation for the the second elution, but tracking multiple RT values would be a pretty radical change to our data model, not to mention our user interface.

Brian

Thanks Brian,

I also used this trick and simply created the number of targets matching the number of isobaric peaks in the LC.
Was thinking that may be it is possible to use some of magic keys ( Cntrl, Shift etc) to make system pick up all peaks assigned to particular target
with multiple isobaric peaks but looks like I was out of luck. Not a big deal, but may be something for a future as I saw similar problems being presented at ASMS user meeting during analysis of released glycans. Basically the same issue. Our problem that we are analyzing glycopeptides and creating iRT library is just not feasible not to mention that our nanoLC RT is much less reproducible. Also number of samples would not warrant going into such extents.

On a similar but a bit different topic. I mentioned that sometimes during loading of Thermo RAW files into Skyline some of the weaker signals are lost.
I could recover them by doing mzML or mzXML conversion by myself in the ProteoWizard and then importing alraedy converted files into Skyline. Though this raises very interesting question on default parameters used by Skyline for RAW data conversion and if there a flexibility for user to alter them ? We are really trying to peek into the grass and removing low abundant signals is not desirable.

Second issue is a bit more tricky. During integration of low abundant signals I frequently mentioned that for some unknown to me reason integration was stopping either half-way reaching the peak maximum or sometimes even not reaching it at all (enclosed). It also dependent on a number of targets. My rudimentary understanding on how things works tells me that it has something to do with default integration parameters used either for peptide or small molecules. I have a hunch that they are actually not the same as same peak not picked up when the same mass was defined as modified peptide, was sort of picked up when defined as a small molecule. My question is which parameters I need to tweak in order to make sure that all my grass is picked up. I dont mind manually correcting integration boundaries, but sometimes they are defined for me without any chance to expand them, which is where the real inconvenience starts. I have a feeling that this time I would really need to upload staff :-)

Cheers

Victor

Actually Skyline doesn't do any conversion, though it will ask the vendor-provided reader libraries to perform centroiding if your Full Scan settings ask for that. Assuming you haven't applied any kind of filters in your msconvert conversion, Skyline won't act any differently with mzML or raw data, other than the fact that Skyline doesn't support centroiding of mzML since we leave that to the vendor libraries. Without knowing what Skyline or msconvert settings you are using, I would guess that by converting to mzML you are effectively forcing Skyline to work on profile data, which you could do without the conversion step.

As to the truncated peak, what version of Skyline are you using?

Cheers

Brian

Thanks Brian,
Are data on qExactive are acquired in centroided mode in both MS and MSMS mode. SO in a way they are already centroided. Not sure how it affects
conversion inside Skyline but I have a feeling that doing conversion in msconvert actually allows for a bit more control. The question about mzML or mzXML is not so clear to me as we saw there are clear differences in Skyline interpretation of very same data. I am not going deep into their details but looks like both come with some limitations for my particular workflow and if there is a way to fix peak truncation then for sure mzXML would be my preferred option as it retains info on fragment ions, something which was missing in mzML.

Talking about peak truncation issues currently I am using 64-bit 4.1.0.11714 Skyline version. Do you think that it is version specific problem ?

Cheers

Victor

Not sure what to tell you - msconvert and Skyline use the same ProteoWizard libraries to read mass spec data, so unless you're doing some kind of manipulation during conversion to mzML there should be no difference between Skyline's use of mzML and raw data. Indeed, we have lots of automated tests that depend on that being the case.

It's also surprising that you find mzXML retains more information than mzML. Could you provide examples of this?

I ask about version number because I think another developer here has been looking at the truncation issue, it will help in my discussion there.

Thanks

Brian

There are a couple of reasons that your chromatograms could look truncated like that:
1. On
Settings > Transition Settings > Full Scan
under "Retention Time Filtering"
you have chosen to only include scans within a certain number of minutes of the predicted retention time

2. You have a scheduled PRM method where you only collected data for your precursors over a certain time interval. When you have both MS1 data and MS2 data for a particular precursor, and the MS2 data only exists over a narrow time range, Skyline will also truncate the MS1 chromatograms so that they are the same length as the MS2 chromatograms.
Another time this can happen is if it was actually DDA data. With DDA data, a particular precursor does not get sampled on any predictable schedule. On page 6 of "Integration2.pptx", your chromatogram looks like what you get if you tell Skyline that your DDA data is actually PRM. There seems to be a point on the chromatogram at 45 minutes, 75 minutes, and 78 minutes.

It might be helpful if you sent us your dataset.

In Skyline, you can use the menu item:
File > Share > (complete)
to create a .zip file containing your Skyline document and supporting files including extracted chromatograms.

You can upload that .zip file here:
https://skyline.ms/files.url

You should also send us at least one of your .raw files.

It looks like DDA data to me. Did you look at the original PPTX file? There are very few points across the MS/MS chromatograms, but plenty across the MS1 chromatograms. It looks to me like the MS/MS spectra were collected dependent on the MS1 spectra (i.e. DDA).

Hi guys,

I uploaded Skyline zipped folder along with both mzML and mzXML files.

The data were acquired in centroided MS1 and MS2 mode on qE using DDA. Indeed, Nick, you are right particular mass was also detected at 34, 45, 52, 68.9, and 82.7 min. Thats why we are using qualifier ions to separate the rest from the real signal eluting at 29 min. In real case I am actually using 7 qualifiers. We need 200% certainty.

I re-checked Retention Time Filtering settings and they were actually set to "Include all matching scans" regardless of MSMS ID times. So we are all clean there. Even when those RT Settings are verifiably lax there was truncation in mzXML file with 2 fragments being detected, while mzML file showed reverse behaviour: peak@29 min was fully integrated and both existing fragments were fully missed. This is puzzling bit, which makes me unsure about the way conversion is actually handled.

Answering on Brian question in msconvert I only included MS levels 1-2, unticked Write index and TPP compatibility, did not use ZLIB compression. BInary precision was set to 32 bit. I also checked another conversion with peakPicking set at true for MS levels 1 and 2 with Vendor preferred box ticked. No difference whatsoever.

Nevermind. Though this raises very interesting question what would happen if we remove MS/MS filtering Option in Skyline alltogether. In such a case both mzML and mzXML were fully integrated and obviously fragments were missed. So there is something in both conversions which makes them either truncate peak of interest or miss present fragments, when MSMS filtering activated. May be I just need to try other 4 options for Product mass analyzer. Not sure it will help but what the heck.

Was thinking may there is a way to re-train peak detection/integration on this particular set of data. I explored a bit this topic just not sure whether it will be of real help here.

Cheers

P.S. RAW file was added as well.